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

is not an accessible name - regardless of how it is implemented - a 'text alternative' given the folloing bullet point in SC 1.1.1:

"If non-text content is a control or accepts user input, then it has a name that describes its purpose."

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?

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. 

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? 



-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Saturday, 25 July 2020 8:47 PM
To: Adam Cooper; w3c-wai-ig@w3.org
Subject: Re: Question about proper use of screen readers in 508 testing

On 25/07/2020 05:53, Adam Cooper wrote:
> I'd argue that this kind of repetition caused by developer ignorance is a hard failure of 1.1.1 because the text alternative does not serve an equivalent purpose to the non-text content.

It's only a 1.1.1 if it's the alternative for a non-text element. So 
there's probably an argument that if the button was a graphical button, 
and it had something like

<button><img src="..." alt="Back button"></button>

leading to the double "button button" announcement, that that could 
indeed be a light ding against 1.1.1 (though certainly, I'd say, not a 
"critical" issue).

If this was due to something like an extra aria-label or similar, 
though, it's not, I'd say, a 1.1.1 failure, as that aria-label is not a 
"text alternatives for [...] non-text content".

<button aria-label="Back button">Back</button>

But yes, it depends on the very specific situation.

> If the label on the button included the word 'button' or the column heading in a data table had header text repeated three times or some other feature had 'global navigation navigation region' as a heading, it would be resolved as a functional defect and reasonably quickly.
> 
> Accessibility is usability for people with disability - the notion that they are somehow fundamentally different disciplines is problematic.
> 
> And shoehorning the evaluation of accessibility into functional testing and within everyday severity/criticality metrics is similarly problematic.
> 
> In any case, de-valuing such defects as 'usability' or something not to be fixed says much about our attitudes to both quality and user experience ...

Not arguing that things that may fall under a more broad "usability" 
category should not be fixed. Never did. However, the distinction I'm 
making is that you can't try to force that fix by flagging it as a 
failure of a success criterion / spec when it isn't. That's what I 
object to...and I still see far too often: auditors flagging something 
as a hard/critical FAIL of an SC, when it turns out it's not 
really/they're just creatively stretching the definition of an SC, to 
give more weight to their request to fix something.

Of course, on the flip side, you have sites/clients that refuse to make 
any changes unless you tell them it violates an SC/the law. But then, 
you have more fundamental problems (of a company being after 
"compliance" rather than actual "accessibility" in the broader sense).

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:13:21 UTC