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


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Angela French
Sent: Wednesday, July 20, 2016 10:17 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] please test my accordions

Bryan,
Can you explain to me please what is actually occurring on my test page as a result of using role="tab".
Can you also tell me when the APG 1.1 revision will be released?

Thank you,
Angela French

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Bryan Garaventa
Sent: Tuesday, July 19, 2016 3:10 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] please test my accordions

Yes, please don't use ARIA Tabs for accordions.

The ARIA Tab markup is causing accessibility issues in this example.

The use of ARIA Tab roles is no longer going to be a recommendation by the W3C for Accordions as previously documented in APG 1.0 because it presents too many issues across differing disability types and ATs, and instead as of the ARIA Authoring Practices Guide 1.1 revision will use this new design pattern instead:
https://lists.w3.org/Archives/Public/public-aria/2016Jul/0143.html



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


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: Tuesday, July 19, 2016 3:08 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] please test my accordions

Hi Angela

This very pattern is going through an ARIA Authoring Practices review and we are proposing a much simpler implementation for accordions.
Not to assume the conclusion of the review, but here are the roles that I have used and recommended for effective and accessible accordion implementation.
1. REmove all the tablist and tab roles (when using role="tab" make sure you use it on the focusable/actionable element, not on its parent).
This bad:
<li role="tab"><a href="#">Do something</a></li> THis better <li><a href="#" role="tab">Do something</a></li>

For accordions you don't need the tab or tablist roles.
2. The actionable item to expand or collapse the tab shouldn't point anywhere, it should be a toggle control (you click it to expand or collapse the tabpanel content).
In fact it is best to use buttons, but links are ok to, as long as they don't point anywhere.
The buttons/toggle controls should have aria-expanded and aria-controls.
Make sure aria-expanded="false" is present in the html by default when button controls collapsed content. This will ensure that screen readers announce the state and users realize the function of the control.

3. Use the region role and aria-labelledby (not aria-expanded) on the content controlled by the buttons (basically replace tabpanel with region and remove aria-expanded).

Example:
<button id="b1" aria-expanded="false" aria-controls="r1">Toggle control 1</button> <div role="region" aria-labelledby="b1" class="hidden"> Content for the accordion controlled by b1.
</div>

When expanded you just set aria-expanded on the button to true and remove class="hidden" (assuming that class is display: none;".
-B


On 7/19/16, Angela French < <EMAIL REMOVED> > wrote:
> Hello,
> I am hoping one or two of you that use screen readers could test this
> simple test
> page<http://www.dev.sbctc.edu/_testing/test-anchor-asset-1.aspx>; I have made. I'm not sure that the aria attributes are correct.
>
> I'd like to confirm that each accordion opens and that the content
> inside is revealed. Secondly, I'd like to know if the link that is
> inside of Accordion 11 reveals the content that it is linking to that
> is inside of Accordion 12. This depends on jquery to inject changes
> and I'm just not convinced it is all working correctly for screen readers.
>
> As always, I'm grateful for your assistance.
>
>
>
> Angela French
> Internet/Intranet Specialist
> Washington State Board for Community and Technical Colleges
> 360-704-4316
> <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >
> www.sbctc.edu<;http://www.sbctc.edu/>;
>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.