WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: please test my accordions

for

From: Bryan Garaventa
Date: Jul 20, 2016 5:28PM

Hi,
In looking at your tabs, the following description is the same as documented at
https://www.w3.org/Bugs/Public/show_bug.cgi?id&254

Specifically, the following sections apply:

The use of ARIA Tab markup for accordions conflicts with documented layout structure for actual ARIA Tabs.
From a screen reader perspective, both sound exactly the same regardless of markup differences, because both use ARIA Tab markup to convey functionality.
As a result, it is impossible for screen reader users to identify the differences between an Accordion where content is rendered inline with the triggering element, and a Tab group where content is rendered after or adjacent to a list of tab controls, because both are identified as "Tab".
This also presents reading order issues for screen reader users, where if a Tab is activated for an accordion and content is rendered inline, it pushes all other Tabs below that point in the DOM reading order, making it appear that orphaned Tab controls are located elsewhere on the page, causing further confusion if an expanded Accordion panel includes an actual Tab group that also includes ARIA Tab markup where its content is rendered after the Tablist according to spec.

Additionally, regarding the specific markup though, the following is the triggering element as extracted from the original demo:

<div class="panel-heading" id="headingaccordion11" role="tab">
<h2><a aria-expanded="true" aria-controls="collapseaccordion11" href="#collapseaccordion11" data-toggle="collapse" data-parent="#accordion1"><span class="glyphicon glyphicon-plus-minus no-print" aria-hidden="true"></span>ID accordion11</a></h2>
</div>
 
Within this markup there are three different role types, a tab, a heading, and an expandable link, and a tab cannot support any embedded focusable elements like a link. The reason being that a tab is an interactive widget that is meant to receive focus, and it cannot be a tab, a heading, and an expandable link all at the same time. The use of ARIA Tab markup for such a construct is going to complicate your ability to use it and make it scale properly as you embed different levels of accordions. Moreover all supporting attributes for role=tab such as aria-selected, aria-expanded, aria-controls, and so on are only valid on the element with role=tab that must be either directly focusable or directly referenceable via aria-activedescendant on the focusable container with role=tablist.

To experience the difference in action, please test your implementation using JAWS and NVDA in IE11, Firefox, and Chrome on Windows, and using VoiceOver on iOS and observe how it sounds when using basic navigation on Windows such as using the Down arrow to go from top to bottom of the page, as well as when tabbing. Then compare this when using touch on iOS.

Now, please do the same on the following demo and see how they differ:
http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm
You can also download this for viewing offline at
http://whatsock.com/test/w3c/ARIA%20Accordions.zip

You can also use Visual ARIA on the second demo to see how the new design pattern uses different ARIA attributes instead of ARIA Tab roles to achieve this control type more accessibly across devices and platforms.

This should help better illustrate the differences both visually and with real testing data to observe in action.

The ARIA Authoring Practices Guide 1.0 has officially been retired already, and all future references as noted for ARIA 1.1 will point to the following resource location instead:
http://www.w3.org/TR/wai-aria-practices-1.1/

The Accordion section is what we are currently working on, using the second demo above as the design pattern to base the new Accordion section on in the near future.

Hopefully this helps explain things a bit.

Kind regards,
Bryan


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.SSBBartGroup.com