WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: building accessible javascript accordions?

for

From: Bryan Garaventa
Date: Aug 2, 2013 11:02AM

I understand the confusion, and unfortunately it doesn't help that many
public references use these terms inappropriately.

An ARIA Widget is a component that is specifically mapped in the
accessibility tree within the browser, and all valid ARIA Widget types are
defined at
http://www.w3.org/TR/wai-aria/roles
Which include Menu, Tab, Slider, Listbox, Radio, Button, Checkbox, etc. If a
particular widget type is not listed with a specific role here, for a
specific interaction type, then it's not an ARIA Widget.

The link you referenced at
http://www.w3.org/WAI/PF/aria-practices/#accordion
Is actually an interaction design, also known as a pattern design, that
simply outlines how a particular component type can be constructed. This
component is not explicitly mapped in the accessibility tree however, so it
is not an ARIA Widget.

Unfortunately the W3C documentation for building the accordion using
role=tablist and role=tab is totally incorrect, and is guaranteed to cause
accessibility issues for screen reader users, because it breaks the paradigm
that delineates the differing functionalities between a Tab control versus
an Accordion control, which are not the same thing. When role=tab is used
for an accordion, it is literally impossible for screen reader users to
detect the difference between them, when the accordion appears to be a
broken Tab control, since both say "tab". The problem with accordions is
that, for them to work effectively, they cannot have one tab stop, because
the accordion content is inline with the triggering element, effectively
breaking up any so called Tab association grouping between them in the
reading order.

These misconceptions are largely why we have so many implementations that
don't work properly for Assistive Technology users.

I discuss this issue in both the Accordion and ARIA Tab sections at
http://whatsock.com/tsg
Where all of the AccDC TSG interaction designs have successfully been tested
using:
The keyboard with no screen reader running.
NVDA and JAWS 11 through 14 in IE8 using Win XP.
NVDA and JAWS 12 through 14 in IE 9 and 10 using Win7.
NVDA and JAWS 14 in IE 10 using Win8.
NVDA and JAWS 12 through 14 in FF using Win XP, Win7, and Win8.
Voiceover in Safari using iOS on iPhone/iPad.

There are always going to be some differences, such as JAWS working best in
IE, and NVDA working best in FF, but these are the most reliable interaction
designs I was able to construct, which is a culmination of four years of
constant testing and development.

I'll include the WebAim group if anyone wants to add feedback.



----- Original Message -----
From: "Alastair Campbell" < <EMAIL REMOVED> >
To: "Bryan Garaventa" < <EMAIL REMOVED> >
Sent: Friday, August 02, 2013 3:12 AM
Subject: Re: [WebAIM] building accessible javascript accordions?


> Bryan Garaventa wrote:
>> I'm not really sure what the difficulty here is, an accordion is actually
>> a
>> pretty simple component type, and it's not an ARIA widget. You can use
>> ARIA
>> to make an accordion, but there is no such thing as an ARIA Accordion.
>
> Hi Bryan,
>
> Minor point (so off list), but if there is an accordion pattern do you
> not consider that an ARIA widget?
> http://www.w3.org/WAI/PF/aria-practices/#accordion
>
> It seems that it is distinguished by a role of tablist and having
> aria-multiselectable="true".
>
> In most cases I prefer the approach you suggested, it's just when to
> recommend each approach that I'm struggling with...
>
> -Alastair