Re: Question about proper use of screen readers in 508 testing

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