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

 Are people familiar with the section of the WCAG 2.x standard that requires ensuring content works with  assistive technology and browsers that users rely on?  It's conformance requirement #4.   
The associated understanding document, explains: 
"The Working Group, therefore, limited itself to defining what constituted support and defers the judgment of how much, how many, or which AT must support a technology to the community and to entities closer to each situation that set requirements for an organization, purchase, community, etc.The Working Group, therefore, limited itself to defining what constituted support and defers the judgment of how much, how many, or which AT must support a technology to the community and to entities closer to each situation that set requirements for an organization, purchase, community, etc.
The Working Group encourages more discussion of this topic in the general forum of society since this lack of generally available yet robust assistive technologies is a problem that affects users, technology developers and authors negatively."



    On Saturday, July 25, 2020, 06:53:11 a.m. EDT, Patrick H. Lauke <redux@splintered.co.uk> wrote:  
 
 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