Regarding an issue in the ARIA best practices doc that contradicts the ARIA spec

Hi,
I'm in the process of building an ARIA test suite for SSB that is supposed 
to be used for building out a matrix of AT/browser support for various 
interactive widget types, in order to determine specifically where screen 
reader support diverges from browser Accessibility API support. So my task 
is to program the components precisely according to the ARIA Role and 
Supported Attributes specs.

Since this will also be used to conduct a comparative accessibility analysis 
of third party libraries like jQuery UI and Dojo Digits, I also need to 
build some interactive widgets that aren't necessarily mapped to specific 
ARIA roles, like an accordion.

This is where the problem is though.

Since I need to use the W3C documentation explicitly for this, I'm 
referencing the W3C ARIA authoring practices guide at
http://www.w3.org/TR/wai-aria-practices/#accordion

According to the doc, role=tablist and role=tab should be used for this 
purpose, and aria-multiselectable=true should be used to specify 'accordion' 
functionality instead of that of an ARIA Tab widget.

E.G
"This will enable an assistive technology, such as screen reader, to convey 
that the tablist is an accordion or a multiselectable tablist. This will 
also tell the user that the keyboard navigation matches an accordion and not 
a tablist."

One problem is that an accordion follows a different markup paradigm than a 
Tab group, where content for an accordion is inserted inline with the 
triggering element, as opposed to a Tab group, where content is inserted 
after the group of Tab links in a separate container.

E.G

[container]
*Accordion trigger one*
[Accordion one container]
*Accordion trigger two*
[Accordion two container]
[/container]

As opposed to:

[container]
*Tab trigger one*
*Tab trigger two*
[/container]
[Tab container]

If role=tablist and role=tab is used for the accordion paradigm, it presents 
nesting conflicts for screen reader users when other ARIA widget types are 
included within the expandable accordion panels. For example, if the 
accordion panel includes another ARIA Tab construct, you then have nested 
tablist containers. It also makes it impossible for screen reader users to 
differentiate between the two component types in the reading order.

The second issue is where the instructions contradict the ARIA spec for 
aria-multiselectable, which makes no mention of changing the functionality 
of ARIA Tabs to that of an accordion:
http://www.w3.org/TR/2011/CR-wai-aria-20110118/states_and_properties#aria-multiselectable
Nor in the User Agent spec at:
http://www.w3.org/TR/wai-aria-implementation/

So, if I program the accordion according to the W3C ARIA authoring practices 
page, I'm actually going against what the ARIA spec specifies.

I've built two test cases to demonstrate this behavior, where you can see 
from screen reader feedback in JAWS and NVDA how confusing it is.

Test case A is programmed using markup and ARIA attribute handling that 
exactly matches that specified in the W3C authoring practices guide:
A: http://whatsock.com/test/w3c/test2/demo.htm
http://whatsock.com/test/w3c/test2.zip

Test case B is programmed using an ARIA Toggle construct instead, which is 
what I would propose using instead, since it makes much more sense when 
viewed using a screen reader, and doesn't present any nesting feedback or 
reading order issues:
B: http://whatsock.com/test/w3c/test1/demo.htm
http://whatsock.com/test/w3c/test1.zip

Side note: I've programmed the Tabs to expand using the Space and Enter 
keys.

I apologize if this has already been addressed. I submitted a bug about this 
amongst some others a few months back, but I have no way of knowing if they 
are still in a queue somewhere.

All the best,
Bryan

Received on Monday, 28 October 2013 18:19:29 UTC