does a control that exposes an incorrect/inappropriate role fail 4.1.2 or not

patrickhlauke commented 2 years ago

A recent discussion bubbled this one up again...take the classic example of a link that acts as a button (triggers in-page functionality), or something like a select that for some reason is exposed as a button, or similar - basically, controls that expose a role, but one that does not actually reflect reality of what the controls do.

<a href="#" onclick="...">Trigger</a>

<select ... role="button">
  <option ...> ... </option>
  <option ...> ... </option>
  <option ...> ... </option>
</select>

Are these failures of 4.1.2? My take so far has been yes. However, I've now heard arguments that 4.1.2 only says that controls need to expose "a" role, and not necessarily the correct one... (ditto for attributes/properties)

The understanding for 4.1.2 is very generic here and doesn't quite commit to anything here https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html

(and yes, ironically ages ago in a different discussion, I have been making the point that for the name part of this SC, it does indeed not specify that the name needs to be correct or not, because there are more specific other SCs that deal with appropriateness of labels https://github.com/w3c/wcag/issues/929 ... but in this case, for the role, it makes sense to me that there's an implicit "correct role" interpretation here - same as for value, state, etc ... as otherwise what's the point if something that has exposes things completely wrongly passes?)

JAWS-test commented 2 years ago

In my opinion, the intention of 4.1.2 is that an element does not have any role and status, but the correct role and status

https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA4:

Check that the characteristics of the user interface component are described by the role.

patrickhlauke commented 2 years ago

whatever consensus we (hopefully) reach, i'd suggest the understanding document should be expanded with some more clarification either way

mraccess77 commented 2 years ago

The text of the SC seems to focus on presence of the accessibility properties. If a missing or incorrect property that doesn't have a visual equivalent causes a compatibility issue with assistive technology then it seems likely to put it under SC 4.1.2 as it is in the robust principle.

Since links and buttons are so widely misused visually for all users it seems like an overstep for 4.1.2 to enforce link or button roles and SC 1.3.1 seems like a more appropriate place to discuss.

Other incorrect states, roles, or values, would likely be a fail of SC 1.3.1 or 4.1.2 depending on what they communicated. For example, incorrect or missing state. would be a 1.3.1 issue if there was a visual equivalent that was different - but if there was an incorrect ARIA structure that was not visually present but prevented screen readers from working then it would be a SC 4.1.2 issue.

Keyboard patterns, roles, and properties are very tightly related in how APIs and assistive technology work and an incorrect role/state can break this structure and thus a correct structure for some things is absolutely needed - but links vs. button doesn't seem to fit that in my opinion.

patrickhlauke commented 2 years ago

Since links and buttons are so widely misused visually for all users it seems like an overstep for 4.1.2 to enforce link or button roles

anecdotally, we've been consistently failing these cases under 4.1.2 for years at my current and last place.

Other incorrect states, roles, or values, would likely be a fail of SC 1.3.1 or 4.1.2 depending on what they communicated. For example, incorrect or missing state. would be a 1.3.1 issue if there was a visual equivalent that was different - but if there was an incorrect ARIA structure that was not visually present but prevented screen readers from working then it would be a SC 4.1.2 issue.

interesting. again, taking an example of, say, an incorrectly implemented tab panel (that visually looks like one, but lacks appropriate role/state), we've again been failing these under 4.1.2 - it's probably on the cusp between where you draw the line between "information, structure, and relationships" (1.3.1) versus "states, properties, and values" (4.1.2)

Keyboard patterns, roles, and properties are very tightly related in how APIs and assistive technology work and an incorrect role/state can break this structure and thus a correct structure for some things is absolutely needed - but links vs. button doesn't seem to fit that in my opinion.

the exposed role (which is then communicated to the user via their AT) sets certain expectations ("what is this thing?") - if the wrong expectation/role is sent along, that's a (mild in some cases) problem for users.

mraccess77 commented 2 years ago

Generally something that is a problem for all users has historically not ben accessibility issue. It's more nuanced but that is what the AG has historically said. A submit button both navigates to a different page and submits data - yet it's a button in HTML.

Most users - with or without vision or with and without cognitive disabilities often don't know what clicking on a call to action item will do - it's often based on the textual wording because the visuals are often so unclear to all users. I just clicked on a button 5 minutes ago that scrolled the screen down - much like a intra-document link - but it was visually presented as a button and it was confusing to all users.

patrickhlauke commented 2 years ago

Generally something that is a problem for all users has historically not ben accessibility issue. It's more nuanced but that is what the AG has historically said. A submit button both navigates to a different page and submits data - yet it's a button in HTML.

But often these sorts of mismatches aren't necessarily problems for all users, but affect AT users (leaving aside the relatively minor issue of link vs button, but the more complex cases of inappropriate/incomplete ARIA roles/states/properties) more (since they'll experience what the underlying markup/attributes "promise" a control is/does/its current state)

Most users - with or without vision or with and without cognitive disabilities often don't know what clicking on a call to action item will do - it's often based on the textual wording because the visuals are often so unclear to all users. I just clicked on a button 5 minutes ago that scrolled the screen down - much like a intra-document link - but it was visually presented as a button and it was confusing to all users.

scrolling would, to me, be ok as it's an in-page action, so a button (if it was exposed as such) would fit that paradigm. again, moving beyond the basic/minor link vs button and to the more general "does 4.1.2 just mandate that 'some' role/properties are exposed, or that the correct role/properties for what the control represents are exposed"

mraccess77 commented 2 years ago

Practically speaking I would likely fail incorrect roles and states beyond links/buttons under SC 4.1.2 for simplicity because it's more aimed at custom controls (although it is not limited to custom controls).

awkawk commented 2 years ago

I would agree that "correct" is implied. It seems to be that ARIA4 is the main place where this is clearly stated, and that is non-normative, so we don't have much to go on. I don't believe that the intent of the working group would be, or was, that any role would do, so I am comfortable with the Working Group updating the non-normative resources to support alignment of 4.1.2 conformance with use of the right role.

That said, I don't think that there is sufficient agreement on link/button to allow us to indicate that a button that looks like a link or a link that looks like a button is an error against 4.1.2. Adding to Patrick's anecdote, any issue reported on a link or button having the wrong role (link or button) we will mark as not a WCAG violation and evaluate whether there is a problem for end-users that requires attention.

detlevhfischer commented 2 years ago

What do you do with situations where the "promised" keyboard pattern works (sort of, but is extended)? I am thinking of a tablist/panel pattern where the role mark-up is as recommended, tabs can be focused using arrow keys, but the tab key also works for traversing the tabs (panels then swapped out by ENTER/spacebar) - meaning that one part of the "promised" pattern, namely, "next tab position will be on the first interactive element in the visible panel" or (if there is none) "focus will move to content after the panel" is broken. I would find it difficult to justify a FAIL for such a modified pattern if the rationale is to accommodate sighted kb users users who expect tabbing to tabs to work.

patrickhlauke commented 2 years ago

i'm explicitly not touching on anything relating to keyboard behaviors here, but just around the promise of what the effect/nature of a control is (is it a link navigating somewhere? is it a <select> that will open up and provide more options to choose from? etc)

for keyboard-related, i only note pass/fails under 2.1.1 (which also doesn't specify which keyboard patterns a particular control must follow, only that there must be some way to operate things with a keyboard). anything beyond that we note as a best practice suggestion, not any kind of failure.

stevefaulkner commented 2 years ago

I don't think that there is sufficient agreement on link/button to allow us to indicate that a button that looks like a link or a link that looks like a button is an error against 4.1.2.

I agree on the look aspect, but what about a button that is functioning as a link? for example: <button onclick="navigateTo('https//w3.org')">W3C</button>

If this is not considered a fail, how about a list of controls functioning as a list of links?

<nav>
<ul>
<li><button onclick="navigateTo('https//w3.org')">W3C</button>
<li><button onclick="navigateTo('https//whatwg.org')">WHATWG</button>
<li><button onclick="navigateTo('https//w3schools.org')">W3Schools</button>
...
</ul>
</nav>

or links with role=button

<nav>
<ul>
<li><a href="https//w3.org" role="button">W3C</a>
<li><a href="https//whatwg.org" role="button">WHATWG</a>
<li><a href="https//w3schools.org" role="button">W3Schools</a>
...
</ul>
</nav>

alastc commented 2 years ago

what about a button that is functioning as a link?

Buttons are fairly generic, I can't see anything in the HTML or ARIA specs that would say that usage is invalid.

From a user point of view, buttons often seem to load a new page (e.g. submit, or modals opening are essentially a form of navigation), so I'm not sure there is such a strong expectation of links vs buttons.

The use of <nav> makes that an interesting case, as a nav should contain links. I might fail that case, but not the independent button acting as a link.

patrickhlauke commented 2 years ago

I agree on the look aspect, but what about a button that is functioning as a link?

users should probably expect that a button can either do something on the current page, OR end up on a different page (think of standard submit buttons in forms for instance). it's overengineered rubbish, but don't think it would completely confuse/take a user aback...

scottaohara commented 2 years ago

I'd find it very suspect if someone were to let individual instances of interchangeable use of links/buttons go, but if buttons were used within the context of a navigation - that somehow became unacceptable. Especially since, if anything, the navigation landmark should give AT users better context that "hey, in this instance, you are probably safer to assume these will behave like hyperlinks, rather than the guesswork you have to do the rest of the time"

aardrian commented 2 years ago

From a user point of view, buttons often seem to load a new page (e.g. submit, or modals opening are essentially a form of navigation), so I'm not sure there is such a strong expectation of links vs buttons.

Which user? A screen reader toggling a disclosure button has dramatically different output than following a link.

alastc commented 2 years ago

I think we are primarily talking about screenreader usage here.

A screen reader toggling a disclosure button has dramatically different output than following a link.

Sure, but a toggle should also have an announcement based on aria-expanded, which should help to set expectations.

A button without any further meaning could either do something, or take you somewhere (or both?). In usability testing I haven't observed people having much expectations of buttons because the results in practice are fairly random.

I'd find it very suspect if someone were to let individual instances of interchangeable use of links/buttons go, but if buttons were used within the context of a navigation - that somehow became unacceptable.

Yea, I haven't thought that through, that exact example hasn't come up for us before. I was taking it from a "what do the specs say", then "what would users expect" point of view. Neither gave me a strong steer!

Note to self: Best summary of the thread so far was from AWK above.

bruce-usab commented 2 years ago

I agree on the look aspect, but what about a button that is functioning as a link?

@stevefaulkner are any of your examples particular barrier for people with disabilities?

stevefaulkner commented 2 years ago

@bruce-usab anecdata from a screen reader user who found that they missed out on links that were not exposed as links as they expected them to be navigable as links using their SR's link navigation keys. For example: in JAWS

List Links INSERT+F7
Next Link TAB
Prior Link SHIFT+TAB
Next Visited Link V
Prior Visited Link SHIFT+V
Open Link ENTER
Open Link in New Window SHIFT+ENTER

brothercake commented 2 years ago

Speech recognition is a relevant use-case here too -- if an element looks like a button, a speech user might reasonably expect that a "click button" command will work, but if it's a link, that command won't work.

This is a case of visual affordance that has an impact on people with disabilities using this kind of assistive tech, so in those terms, I would tend to consider it a failure of 1.3.1, since information conveyed by presentation cannot be correctly determined programmatically.

But to the wider question, I think it would be most helpful and most straightforward if 4.1.2 were clarified to mean that the semantic information must be appropriate, not just present. There's clearly a good deal of overlap between 1.3.1 and 4.1.2, so if a line has to be drawn somewhere, I think that would be the most intuitive place to draw it.

mraccess77 commented 2 years ago

A few observations

Tab and shift+tab will go between links and buttons.
Most modern speech recognition allows users to say things like "show choices" or "show numbers" or speak the name of the control which support both buttons and links
Putting this under SC 1.3.1 would not have the intended gains as if something looks like a button but acts as a link would then require it to be a coded as a button because it is presented like a button.
As Patrick and I have mentioned previously - form buttons navigate to other pages

My thought is that instead of trying to change WCAG 2.0/2.1 that we should really have put this in WCAG 2.2 and we should get this in subsequent WCAG versions with more clarity that address the issues directly. Also requiring that buttons that open dialogs communicate that fact as well would help to give users context. WCAG 2.0 A or AA doesn't even require users be warned about new windows - so I'm not sure the authors intended a fail for buttons and links misused although it seems to be an issue for some users and would make things more accessible.

scottaohara commented 2 years ago

Circling back to what's actually needed to resolve this issue.

People need the working group to confirm whether 4.1.2 is saying "a role must be exposed or "the correct role must be exposed". Per awkawk's comment, I also agree that needing to expose the correct role is implied - but the resolution here should not be a endless dive into the debate about links vs buttons (that's what twitter is for).

To help resolve this issue, I have created a pretty straight forward PR https://github.com/w3c/wcag/pull/2207. If people think there needs to be other changes beyond what I'm proposing, then let's talk about how to make this more clear.

patrickhlauke commented 2 years ago

I'd throw in that "correct role" suggests there's always one unambiguously "correct" one. maybe "appropriate" is a better word?

mraccess77 commented 2 years ago

I'd say appropriate is the best word to use as well! That would provide flexibility for all sides.

scottaohara commented 2 years ago

well i used the word "accurate" in the PR.

we should comment on the PR and what needs to change there, if anything, instead of deciding which word I should have used in my comment about the PR. :)

alastc commented 2 years ago

Ok, so it sounds like we have general agreement that the intent is for appropriate roles to be conveyed for 4.1.2, but that perhaps link vs button is a grey area in terms of what would be appropriate.

I don't think the PR (adjusted to "appropriate") would be a change as such, so that could be merged into 2.1 & 2.2 understanding docs. @awkawk do you see any problem with that? (As someone that might typically object to such changes ;-) )

I wonder if it is worth adding a line to the intent after the paragraph starting "If custom controls are created...", something like: "What roles and states are appropriate to convey to assistive technology is determined by other specifications such as ARIA (link), or the appropriate platform standards. Another factor to consider is whether there is sufficient support in assistive technologies to convey the information as specified."

awkawk commented 2 years ago

@alastc Yes, I think that is fine. I'm more comfortable with "appropriate" and agree that this doesn't eliminate the link/button grey area (which also exists in the ARIA spec).

scottaohara commented 2 years ago

PR has been updated to use the 'appropriate' word, and i've pulled in a slightly modified version of @alastc's suggested paragraph addition.

reasoning for minor editing provided in the commit message.

bruce-usab commented 2 years ago

Thanks @stevefaulkner for those examples. +1 to PR, and agree with folks that less grey is better but also it is okay if we cannot draw perfectly bright lines on the link/button question.

lloydi commented 2 years ago

It seems to me that this is something that has been implemented poorly for so many reasons by so many developers that the people who really would benefit from being provided with reliable information about "what this thing is?" have all but given up on expecting something reliable.

So, the battle is lost? It's been wrong so much that we don't bother fighting that fight?

Literally a hill I'll die on, with but a single sword in my worn-out, bloodied hands, as I face the Armies of Angular, the Vanguards of Vue and the Ready Reserves of React.

It behaves like a button but is indicated as a link? You get smackdown!
It links to a page but is announced as a button? You get my axe!

(OK, I lied, I have an axe and a sword)

patrickhlauke commented 2 years ago

@lloydi if we get "appropriate" or similar wording in per @scottaohara's PR, that's already a good step in the right direction, far from battle being lost. but seeing that there's still edge cases and nuances (e.g. a submit style button also "links to a page", but is clearly acting as a button) don't think we can get more hardline prescriptive than "appropriate", and leave it with the subjective view of an auditor (as it has always been anyway)

matatk commented 2 years ago

This specific thing hasn't been explicitly mentioned, though it chimes with, and perhaps reinforces, others' comments (or perhaps you've been considering it already anyway). The definition of "role", which is linked from the SC's text, is (with the last line being an example):

role

text or number by which software can identify the function of a component within Web content

A number that indicates whether an image functions as a hyperlink, command button, or check box.

Whilst a definition of something isn't the same thing as a requirement expressed in an SC's text, it seems to me that the example in the definition shows that the intention is for a role to reflect how an element behaves in practice. The SC requires that a role is provided, so I take this to mean that the role is intended to be appropriate.

Given this definition is linked from normative SC text, I imagine it's normative too? (Though the Glossary section doesn't state whether it is normative or not, but it seems to me that definitions linked from normative text would need to be normative.) I was in two minds about posting this, as it doesn't add/change anything, except maybe adds more weight to what has already (and reasonably, I feel) been agreed.

I have thoughts about buttons and links. I remember @aardrian saying "links fetch resources; buttons trigger actions" and I try to stick to that, to promote helpful expectation management for AT users. However I accept there are cases where you can activate a "legitimate" button and still end up on another page. I too am happy with @scottaohara's proposed wording; it's a good step forward.

bruce-usab commented 2 years ago

Failure techniques are pretty strong. @lloydi or @matatk — might you try your hand at crafting one for a link acting like a button or vice versa?

aardrian commented 2 years ago

@lloydi or @matatk — might you try your hand at crafting one for a link acting like a button or vice versa?

If you kids take a stab at that, hit me up. Though I think a specific failure for it is overkill, I have notes regardless.

frex65 commented 2 years ago

Jumping in late to the (defunct?) links/buttons discussion, as a screen reader user I tend to assume that activating a link will cause a new page to load while pressing a button will either trigger a same-page action (which may be opening a dialog) or submit a form, in which case loading the resulting page would be expected behaviour. Although I'd consider myself a reasonably expert screen reader and web browser user, I still get caught out at times by links that run scripts and by buttons that load new pages. The subject of whether users with extra needs see the links/buttons issue as a problem has been mooted several times in this thread. IMO this isn't something that the experts can know without asking users directly. I've carried out a very unscientific straw poll of blind screen reader users on Facebook, the results of which I'm pasting below FYI. I'd be v interested in voice recognition users' take on this, but don't know anyone who uses that technology.

Frex65

If you use a screen reader and you're on a website, do you feel there's a difference between links and buttons or do they essentially do the same thing? If they do behave differently, in what way? Me and a few others that I work with are wondering whether blind people feel that buttons and links should do different things when you activate them, or whether they're pretty much interchangeable. Would really appreciate your comment if you have time. Thanks.

User1 (name redacted)

I think buttons usually take you to some thing that you can take an action on, whereas links would take you to another bit of a website. I’m not sure this is always true, but that’s what I would expect. I think it would be better if there was a clear difference between what buttons and links do, but it’s kind of a minor issue with access to websites. The main thing is for buttons to be labeled.

User2 (name redacted)

User1 I agree! From a link I would expect to be able to click into another area, from a button I would expect some sort of reaction! hope this makes sense written in haste

User3 (name redacted)

Hey, they are theoretically quite different things. A link quite literally is a hyperlink to another part of the Internet usually, you can of course have it linked internally but they do use URl within that to direct you to wherever. A button would normally pertain to an action within the website you are visiting. Now of course the technical is behind it, as I would understand it could be similar, but the button France might be next. For instance, I did an online Visa waiver form to enter the United States last week, And they were links to external science, or bottoms that took you to the next part of that website.

User4 (name redacted)

If I need to search a website or fill in a form that’s when I would look for batons.

User5 (name redacted)

User4 me too

User6 (name redacted)

A button is for a search or selecting something whereas a link takes you to somewhere. I hope this makes sense x

User7 (name redacted)

They do different things. Links take you to a new location where you will find more information related to what the link is called. A button iniates an action.

User8 (name redacted)

I don’t know if I can even explain what I know and maybe what I know is not enough to explain. Links are portals for web access and buttons are selectors for actions and form elements.

User9 (name redacted)

I agree with the comments above. Buttons theme to cause actions within the same website where is the link takes you somewhere different. There are times when links are used instead of buttons though I don’t use buttons list all links list very much with any screen reader

User10 (name redacted)

I would presume that a link is going to take me to a different page, and a button is just going to be like a yes no option.

mraccess77 commented 2 years ago

The problem is compounded by the fact that things that are links are designed visually to look like buttons. So people who are not screen reader users and have other disabilities never know what's going to happen either. So any requirement should also address the visual affordance of what will happen.

patrickhlauke commented 2 years ago

and that's where the problem lies... because now you're in the highly subjective "make sure links look like links and not buttons" area...

mbgower commented 1 year ago

Hi folks, I was referred to this unresolved topic after I raised similar concerns at an ARIA session at TPAC this fall.

Lack of consistency between role and visual appearance is a big problem just between buttons and links,. But it also extends to more complex interactions, such as making dropdown menus out of disclosure patterns, etc. The more we invite people to design their own web application patterns, the messier this will become, with end users often the losers. Essentially, the more power we give authors to assign a role to something, the more chance there is for confusion between users of different modalities, especially because keyboard interaction is left in the hands of the author.

To me, the nub of the problem is keyboard operation. A lot of the focus here has been on buttons and links -- because they don't use the same keys to operate. if they did, I don't think anyone would care. But buttons and many controls activate with Spacebar, while links execute exclusively with Enter (unless your AT overrides).

I encountered this problem the other day doing some testing. I activated a language button on a page with my Spacebar

and when the language options opened up, I chose English to continue

Unfortunately, that did not cause the English button to activate. Instead, it moved my viewport down the page.

I was confused.

I suspected, and confirmed with an inspection, that "English" was actually a link disguised as a button. For those who can't see those images, I'll mention that "English" is one of three text labels on a black (when selected or focused) or white (when not selected) rectangular shape with the classic radial/curved corners of a button.

There are many other text-based elements in my screen shot that could be a link or a button. Below English and other language choices, there is a set of text chunks, separated by spacing, for example. Put an underline on them and they would undisputedly be links.

I think it is fairly easy to argue and demonstrate that with some pretty simple design changes, this confusing keyboard experience could be pretty much eliminated.

The issue isn't restricted to activation. A similar problem happens with navigation, where sighted keyboard users are left to figure out if this dropdown is a select or menu, which they open and navigate with the up/down arrow keys, or some kind of faux menu that maybe only opens with the Enter and navigates with Tab.

Some folks have argued above that we can't dictate what appearance something has. I understand the challenge. But in my opinion, if you go back and look at Patrick's original question, there is an inherent acknowledgement that there IS or can be a correct or at least likely role for something. Something that makes Patrick say "Hey, this isn't a radio button!!"? I think much of that is based on appearance.

Just imagine what would happen if every control on a page looked the same. I think sighted users would rapidly realize that there is a lot of visual convention helping their user experience. The APG provides guidance on role and keyboard operation. How can we explore to what degree visual guidance can be recommended?

patrickhlauke commented 1 year ago

big problem just between buttons and links

do we have any actual evidence of this? i hear it being asserted often, but not by actual users (as in "not people involved in accessibility auditing/evaluation") in the wild, empirically

buttons and many controls activate with Spacebar, while links execute with Enter

buttons also activate on enter.

The APG provides guidance on role and keyboard operation. How can we explore to what degree visual guidance can be recommended?

I'm really uncomfortable about making any sweeping normative changes/additions to SCs that start to enshrine "if you don't design a certain way, you fail WCAG". this simply won't fly. and we've seen how maddening it can be to try and normatively define visual aspects even for basic things like focus appearance...now imagine having to normatively define at what point a button looks "correctly" like a button, and where you draw the line between links that are calls to action and links that are styled almost like a button.

If instead you were thinking of a non-normative note or best practice advice, sure.

mbgower commented 1 year ago

i hear it being asserted often, but not by actual users

Although the Mac I switched to makes it a lot tougher for a guy that grew up on Windows, I use a keyboard as my predominant means of interaction when possible. So I experience these problems/annoyances frequently. I'm lucky, in that I can resort to a mouse when the keyboard operation gets onerous or impossible. No, I have not done such a research review you ask about.

I'm really uncomfortable about making any sweeping normative changes/additions to SCs that start to enshrine 'if you don't design a certain way, you fail WCAG". this simply won't fly.... If instead you were thinking of a non-normative note or best practice advice, sure.

Yes, I meant recommendations. The APG is not normative, correct? All its guidance on keyboard operation and patterns constitute recommendations, not requirements, I believe.

I know Matt King was concerned with the scope creep that just an endeavour could introduce into the APG. But maybe if we brought in visual designers for an adjunct project, we could try to provide a baseline?

patrickhlauke commented 1 year ago

Yes, I meant recommendations. The APG is not normative, correct? All its guidance on keyboard operation and patterns constitute recommendations, not requirements, I believe.

sure. but we're here in the WCAG repo, so assumed you meant "as part of WCAG".

in your original (edited now) comment you mentioned "Leaving that point aside, your response suggests your own answer to the starting question for this issue is 'no, a control that exposes an incorrect/inappropriate role does not fail 4.1.2.'". just to clarify, no that's not my stance. my stance is specifically about the idea that a link, that acts as a link, but is styled as a call to action that some people may say is button-like, causes some failure (if not 4.1.2, then 1.3.1 Info and Relationships or similar). that is the dangerous path I'd like to avoid. if the outcome just of this aspect is "we can write something that says 'try not to make your links look too much like buttons' in some kind of handwavy way, sure...though i'd doubt how much people would actually care for that nugget of info

bruce-usab commented 1 year ago

@mbgower – What is APG?

do we have any actual evidence of this?

@patrickhlauke – I hear complaints, from end-users, fairly routinely. The concerns I hear are not from pedants, if that is what you're asking? The end-users typically want me to agree that it is a WCAG violation, and I disappoint them. I agree it is annoying, but it not something that rises to a failure against 1.3.1 or 4.1.2, IMHO. I am open to changing my mind about that, but I cannot think how to draw the line.

bruce-usab commented 1 year ago

Ping to my colleague @kengdoj to ask does TT or Baseline has a requirement for links that visually present as a button?

patrickhlauke commented 1 year ago

@mbgower – What is APG?

https://www.w3.org/WAI/ARIA/apg/

awkawk commented 1 year ago

Lack of consistency between role and visual appearance is a big problem just between buttons and links

@mbgower I use the keyboard a lot also, and I guess I would characterize the experience you describe as an annoyance rather than a big problem. If I hit space for a button-which-is-actually-a-link the page scrolls and I need to hit shift-space to get back to where I was and hit enter. Alternatively, and what I usually do, is hit enter on a button/link that isn't in a form because there isn't the possibility of activating the default button for the form.

This isn't perfect, and is sometimes an annoyance, but hasn't ever blocked me from completing a task.

The problem with links and buttons is that the appearance of links and buttons will continue to evolve, and unless some authority says "Links look like __ and buttons look like ___ and they are for the following clearly defined and non-overlapping semantic purposes" then we are going to forever have this issue.

This issue isn't just with links and buttons, even though that is the most common - would we also fail a set of radio buttons where the buttons are styled to look like checkboxes?

bruce-usab commented 1 year ago

...would we also fail a set of radio buttons where the buttons are styled to look like checkboxes

FWIW, I have (or it might have been checkboxes that looked like radio buttons). More of a problem for someone not using a screen reader! Probably it was a PDF form rather than a web form (because it is an easier mistake to make in PDF).

EDIT (addition): I fail it because circle versus square is such an entrenched behavioral cue. If the form author used rounded rectangles (or some other novel presentation), I would pass.

patrickhlauke commented 1 year ago

would we also fail a set of radio buttons where the buttons are styled to look like checkboxes?

I wouldn't, no

To expand on this, there's certainly degrees in my view of how closely related/similar/appropriate actual exposed roles are compared to their visual design. Yes, we can argue "but then when an SR user talks to a non-SR user, one will talk about 'checkboxes' and the other won't know what they mean because they're radio buttons, or buttons with aria-pressed, or..." ... but that to me really goes to far into "AGWG want to prescribe the visual design of the web to stick to some arbitrary design 'rules' they concocted" territory.

My main concern are things that are very different in nature, like selects that are exposed as buttons but then don't behave like buttons...though admittedly even there, there can be probably be arguments either way...

awkawk commented 1 year ago

Probably it was a PDF form rather than a web form (because it is an easier mistake to make in PDF).

It's pretty easy in HTML too: input[type="radio"] { -webkit-appearance: checkbox; -moz-appearance: checkbox; -ms-appearance: checkbox; }

The place where I see this the most is in government forms where the appearance digitally must match the OMB form. :)

scottaohara commented 1 year ago

i see that @bruce-usab assigned himself to the issue, but I already have a PR #2207 (which bruce has also approved) that has been waiting to be merged since February.

is there something that needs to be updated to the PR? Or is this conversation circling back to the link vs button debate which is a subset of what the issue was trying to resolve? Happy to help update the PR with whatever may need to be done. Just am calling this out to ensure duplicate work isn't done (I actually forgot I even made a PR for this since it's been so long).

patrickhlauke commented 1 year ago

wonder if the nuance that we're teasing out in this discussion can somehow be distilled into some (handwavy?) advice for a note in the understanding of 4.1.2. clearly it seems to come down to "it depends(tm)" / "it's context specific" / "it's a bit subjective", but ideally the exposed role of a control should bear some resemblance to the actual purpose/function of the control (and as bonus best practice, ideally make sure that even visually the presentation of the control is not too alien to what the thing does, but who's to say what that actually means)

bruce-usab commented 1 year ago

@awkawk I am not knocking PDF. Look at all that extra code to make the HTML misbehave! I believe the error was from forms which started as Word documents. It has been a while. Nowadays, does Acrobat enforce the expected behavior unless the author really works hard to do it wrong? At one point in time, and it might have been Word not Acrobat, the choice between checkbox and radio button was framed as being entirely aesthetic.

And fair point about the digital version needing to match a legacy OMB paper form!

w3c / wcag