- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Sun, 26 Jul 2020 01:32:03 +0100
- To: w3c-wai-ig@w3.org
On 26/07/2020 01:12, Adam Cooper wrote: > is not an accessible name - regardless of how it is implemented - a 'text alternative' given the folloing bullet point in SC 1.1.1: It is only a text alternative if it's an alternative to non-text. I.e. with <button aria-label="Blah button">Blah</button> the aria-label, the accessible name, is not a text alternative, as it is not "Text that is programmatically associated with non-text content" https://www.w3.org/TR/WCAG21/#dfn-text-alternative because the button is not "non-text content" https://www.w3.org/TR/WCAG21/#dfn-non-text-content If the button is graphical, like <button aria-label="Some button"><img src="..." alt="..."></button> then yes,you could regard that as the text alternative, because then you *are* dealing with non-text content. So...it depends on the specific situation. > Also, with the repetition of the word button in an accessible name, I'd be interested to understand how this it not a critical issue given this success criterion is Level A. Is this a limitation of WCAG 2.1 or an interpretation? There are things that are critical because they completely stop a user from being able to use/understand a website. Wrap your entire page in aria-hidden="true" ... that's critical. Have buttons and images that expose *no* text alternative/accessible name. That's critical. Have a site that only works with a mouse. That's critical. Have a button that has one redundant word in its announcement? That's an inconvenience, but critical? Hardly. While WCAG is indeed binary (you either pass or fail), there is still room when evaluating to indicate how badly a particular failure is. Having a redundant word is a very mild bug/failure. > In which case, I’d argue that any differences in understandings of this success criterion are not necessarily attempts to stretch meaning to fit a circumstance but just that and probably due to a lack of definitive guidance, inconsistencies and omissions in definition, evaluator experience, demanding clients, and so on. Yes, WCAG is very handwavy and vague, and often internally contradictory. And even people on the working group often disagree about the true meaning/scope of some of the SCs. But I also often see evaluators who creatively reinterpret SCs to fit their own likes/dislikes/bugbears...which in the end means more confusion for everybody since they further muddy the water about what is and isn't normatively a pass or a fail. > If an evaluator can provide a water-tight rationale, then is not a more usable web a better outcome for all than upholding a principle of technical discourse? Because for better or worse, WCAG itself is a standard, and is referenced (either directly or indirectly) by legislations. Saying that it's ok if some evaluators reinterpret things as long as the end result is a better web is...a slippery slope. And again, by all means, evaluators can flag things that might normatively slip through/pass but are not good accessibility and usability. WCAG is only a baseline, a lowest common denominator. But my point is that evaluators should not consciously try and pretend something fails a particular SC when it doesn't. Otherwise, there'd be no point in actually having SCs in the first place if it's all up for grabs anyway. P -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Sunday, 26 July 2020 00:32:18 UTC