WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Intuitiveness of JAWS jump to tabpanel shortcut for ARIA Tabs in FF?

for

From: Bryan Garaventa
Date: Jul 4, 2014 3:13PM

A large part of the problem is that many developers don't actually follow what the spec has documented for specific ARIA Widgets.
For example, at
http://www.w3.org/TR/wai-aria/roles#tab
It's quite clear that an ARIA Tab construct should have only one tab stop.

So when developers implement only the ARIA attributes, but don't include the requisite scripting behaviors,
Or if they don't also coincide focus movement with the necessary elements that include valid roles,
Or if they only implement some of the ARIA attributes but only partially and omit others that are required for that Widget type,
Then the ARIA Widget won't work reliably on any browser or with any Assistive Technology.

Doing all of these things requires a good understanding of HTML, scripting for event handling and focus movement, knowledge of the
ARIA Roles Model spec documentation, and frequent exposure to Assistive Technologies like the most widely used screen readers and
how they behave when ARIA is implemented. Otherwise it's impossible for developers to know when a quirk is the result of a browser
accessibility API issue, a screen reader support issue, or a bad programming issue caused by the developer. For example, if you
implement an ARIA Tab construct and set each tab to load onFocus as documented, then NVDA users will trigger each tab inadvertently
simply by arrowing down the page in Browse Mode, because NVDA automatically triggers the 'focus' handler when reading content in the
virtual buffer.

Cramming all of this information into one developer's head is difficult and takes a lot of time and commitment, which also explains
why we have so many badly implemented ARIA Widget constructs across the web.

Also, it doesn't help that the W3C ARIA Practices document appears to support diverging from what the Roles Model spec has
documented, which is most plainly noticed when comparing the Accordion guidance with the Tab Panel guidance, which is somewhat
counterproductive. I've already raised an issue about this at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26254
(Bug 26254 – WAI-ARIA Authoring Practices include contradictory guidance for Accordions)

Regarding the hotkey assignment for aria-controls in ARIA Tabs, I agree that the shortcut guidance in JAWS should not be limited to
Firefox, so I'll file a bug against this with FS.

Also, I think we agree that the Insert+Alt+M hotkey is difficult at best, and that it should not be necessary to reconfigure JAWS
simply to use a Tab control on a web page effectively, since this also effects blind people with dexterity and motor impairments.
I'll file a bug and see if this can be changed to something a bit easier for people to use, whatever that may be.