Fw: [WebAIM] building accessible javascript accordions?

Hello,
This is a recent discussion we had on the WebAim group, and it exposes a 
critical flaw in the W3C Accordion design pattern. I wished to pass this on 
in case it's helpful to the group. I'd be happy to elaborate further if 
desired.
 Best wishes,
Bryan Garaventa

----- Original Message ----- 
From: "Bryan Garaventa" <bryan.garaventa@whatsock.com>
To: "WebAIM Discussion List" <webaim-forum@list.webaim.org>
Sent: Friday, August 02, 2013 10:02 AM
Subject: Re: [WebAIM] building accessible javascript accordions?


>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" <alastc@gmail.com>
> To: "Bryan Garaventa" <bryan.garaventa@whatsock.com>
> 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
>

Received on Wednesday, 7 August 2013 12:14:49 UTC