Update 3.3.2 understanding doc and g167 technique #4102
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
as not everyone might read this page and then check out every technique to then find the updated G167, I've added two new written examples to the understanding doc as well. (though the one about when instructions might be needed or not is a bit out of scope for this PR, i still thought it might be a nice addition... we can pull it out if people disagree or don't want scope creep)
scottaohara
changed the title
Co-authored-by: Giacomo Petri <[email protected]>
|
Discussed on backlog call 11/1. |
|
I think it would be beneficial to have the far more common case of a search icon (loupe) for the search case, or add that as an icon-only variant after the old school case. I think the commonality of the loupe icon standing for search is undisputed. That is then the core case on which to hang similar cases like the chat message send icon. A line may be added, explaining that this only works when the meaning of the icon used for labelling a field and the context of use can be considered very conventional. Should the test of the technique also check that the icon (in icon-only cases) has a descriptive programmatically determinable name (or label)? With the old school examples this was more or less a given, not so for icon based buttons? |
|
Actually, the commonality of the loupe icon to stand for search was disputed in a discussion here only a few weeks ago. See #4095 where I mentioned three different ways in which that icon is used in different applications. That's not a problem for SC 3.3.2 because it does not require that labels are accurate or meaningful, but SC 2.4.6 does. I would argue that icons are almost never unambiguously meaningful with the possible exception of icons that occur in the user agent and are used in the same way in the website. |
|
@TestPartners I agree there are different interpretations of the loupe, but I think this is not an issue when you take into account the context in which it is used (after a search field, or on a map or image). There can hardly be a more ubiquitous pattern on the web than a text field followed by a loupe icon? |
|
You say the context is that the icon is "after a search field", but users don't know it's a search field unless they understand what the icon means. I'm really not happy saying "everyone know what this icon means". Even if we agree that the loupe is universally recognisable, many (most?) other icons are not. I would like to see G167 clearly state that the use of icons as labels is conformant with SC 3.3.2 but that it is not conformant with 2.4.6. |
I guess it is clear that the field itself would need an accessible name, so for non-visual use this would not be an issue?
It won't ever be "everyone" - when could you ever be able to make such a sweeping claim? Exactly, never. There are many places where implict assumptions and conventionality play a role in interpreting and understanding, and you are managing tradeoffs here all the time. You can say the same thing about the play and pause icon - sure you will find some people who don't know them. How far will you get when you say "every visual element needs a text description next to it" or "you must not use the loupe icon, the hamburger icon, the play icon etc. because they fail 2.4.6"? |
I'm not sure everybody agrees with that last bit, I'm afraid. Which is the rub. You're trying to make an absolute statement on something that is far more subjective, contextual, and nuanced. Are there uses of icons that are just too cryptic or useless (extreme case, an icon that is just a single 1x1 pixel)? Sure...and using their judgement, auditors can fail those under 2.4.6. But that does not mean that all uses of icons can never pass 2.4.6 |
|
In my view, the last bit is uncontroversial. There are countless examples of icons that have multiple interpretations or no meaning at all. SC 2.4.6 explicitly says it is non-conformant "if the label is not sufficiently clear or descriptive". On that basis, very few icons would be conformant. |
|
"Very few" does not mean "none"... By all means, 2.4.6's understanding should touch on the point of icons being used as labels, and suggest that authors should carefully consider how (subjectively) understandable they are. But an outright "these never pass" is, frankly, naive (unless your aim is to, overnight, make the majority of web content out there non-conformant) |
|
I encounter so many icons that even I don't understand, that I would not object to it being an automatic non-conformance even if a small number are understandable. However, I realise that's not going to happen, so the next best thing is a requirement "that authors should carefully consider how (subjectively) understandable they are". That makes it clear that we can report a non-conformance if we think an icon is not sufficiently understandable. It's worth making the point that text labels can also be subjectively understandable, so it's not just icons. |
|
Discussed on TF call 11/22. It is not controversial that icons (with alt) can be used as labels. Concurrence with PR. |
In the past the group chose to not require on-screen text for icons. Now requiring them would mean a significant change which would in my opinion be on the level of an errrata. |
|
@mraccess77 this pr makes no such claim, nor does it plan to. So no errata necessary |
|
IMO, Detlev's comment requesting an examination of the current wording of the test procedure is valid
In the existing version of this technique the context of the button having a text label is explicit in the pre-amble, and the existing examples support this:
We have introduced icon-only buttons into this technique, but not addressed the preamble, nor the tests, which currently read:
There is no check here that the icon button has an ALT (although that is inferred in changes to the technique content, specifically "with the alternative text of 'search'"). While it is true that an icon-only button without a name would already fail WCAG (4.1.2, 1.1.1, etc), for the purposes of this technique it seems reasonable to include an additional check, since obviously a icon button without a name cannot be said to be labelled. |
Adding a third check
|
Note that I accidentally directed committed my final suggestion:
|
Co-authored-by: Mike Gower <[email protected]>
closes #4088
includes new icon-button example in G167 to showcase how a button represented by an icon alone can be used in certain instances for labeling form fields
also updates the understanding doc to provide two new written examples to the examples section list.
One to not make someone have to know to look to g167 to understand that "icons" can also serve as labels
And the second to provide an example of how two websites could have the same sort of input, but one needs instructions (due to extra requirements) while another doesn't (because they are super chill).