RE: AT implementer woes with acc names

Hi Rich,

I just want to state that this point is raised again and again and that the note content should come best from a group of AT people like other industry members do W3C specs (such as CSS).

Unfortunately, I don’t see such an approach by AT and I don’t know how to actively encourage that since there seems no “screen reader working group” is part of the W3C ecosystem.

Industry should not solve that without participation of AT, too (danger of becoming a life of its own), although for QA we need reliable test procedures that cover the broadest scope of AT.

I’m not talking about button role tests here. The more complex the examples get the more differences pop up
Waiting for a Nash equilibrium between different AT&UA combinations is possibly doomed.
For me this is an existing  gap currently bypassed by local testing procedure workarounds reinventing the wheel on multiple testing places around the globe.

Part of the problem is also the heuristics implemented by different vendors and the resulting custom behavior of AT due to the lack of defined generic events in WAI-ARIA (such as row selection in grids, dialog show/hide etc.). Even the simple toggle of a toggle button is not indicated by a specialized event on all platforms. As a workaround, you have e.g. to refocus the button to retrigger the speech engine on IE, while in Firefox this works without workarounds.

Another example: What shout iOS do when custom HTML “ARIA sliders” should be used with VoiceOver? Swipes simply do not work with the HTML clone (fact) since the corresponding event is not well defined for AT, in contrast to the native iOS control, and inconsequence the swipe does not work when VoiceOver is active.

Sometimes it is necessary that AT traverses the DOM for full content retrieval but nowhere it is exactly specified how deep in parent/child relationships the search should be carried out which is a pain in developer consultations when they ask how to support AT most efficiently.

For the development of ARIA, we should definitively scan where AT “heuristics” are used and try to substitute them by *explicit* declarations. I am sure if you talk with an AT developer they can name you many places where these “guesses” or “heuristics” are applied and these would be good candidates.

To give you another example: Today we have not only buttons but also complex list items on mobile that are active, selectable, deletable, have rich interactive content (diagrams, links, sliders, separate buttons) but still no concept to handle the entity besides of “listitem” or “option” which are seen in the classical way as plain dead text which they aren’t. What should AT do when such a complex list item container is focused? IMHO, role extensibility is desperately needed here but again, not without AT collaboration since the extension concept should be normative.

Best Regards

From: Richard Schwerdtfeger []
Sent: Montag, 4. Januar 2016 23:10
To: Michiel Bijl <>
Cc: Steven Faulkner <>;
Subject: Re: AT implementer woes with acc names

We could do that but the problem is that AT vendors don't want us to do that. In particular they don't want us enforcing it.

Potentially, we could put this in an note but we need to find the cycles. We have a lot of specs. we are delivering.

Rich Schwerdtfeger

[Inactive hide details for Michiel Bijl ---12/17/2015 09:06:51 AM---Excellent article. Is there a way the ARIA spec could clarif]Michiel Bijl ---12/17/2015 09:06:51 AM---Excellent article. Is there a way the ARIA spec could clarify what AT should do? Is that even someth

From: Michiel Bijl <<>>
To: Steven Faulkner <<>>
Date: 12/17/2015 09:06 AM
Subject: Re: AT implementer woes with acc names


Excellent article. Is there a way the ARIA spec could clarify what AT should do? Is that even something we’d want to do?

On 17 Dec 2015, at 10:24, Steve Faulkner <<>> wrote:

Woe-ARIA: The Surprisingly but Ridiculously Complicated World of aria-label/ledby

By james Teh



Current Standards Work @W3C<>

Received on Tuesday, 5 January 2016 09:27:02 UTC