WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: building accessible javascript accordions?

for

From: Steve Green
Date: Aug 1, 2013 6:39PM

There is a difference between accordion menus and accordion content. Our experience of user testing is that screen reader users can usually cope with accordion menus, if only because they can ignore the menu and select the top-level menu item as long as the resulting page contains the same links that are in the menu.

However, such redundancy does not exist with accordion content, and users frequently have no idea what is happening when they operate an accordion link. We have yet to test any accordion content that has ARIA markup so I cannot comment on how effective this might be. However, the previous discussions are not encouraging.

Steve Green

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: 01 August 2013 20:11
To: WebAIM Discussion List
Subject: Re: [WebAIM] building accessible javascript accordions?

Another example can be found at:
http://www.3needs.org/en/testing/code/aria-expanded.html#

I don't think a keyboard interaction model is necessary for simple accordian style menus, user simply activates a link or a button in the usual way and it displays or hides content based on that interaction.
Cheers
-Birkir
Birkir Gunnarsson
Accessibility Subject Matter Expert | Deque Systems www.deque.com

On 8/1/13, Bryan Garaventa < <EMAIL REMOVED> > 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.
>
> For example, I typically recommend making each triggering element
> either an
>
> ARIA Toggle using role=button, aria-pressed=true/false, and
> aria-expanded=true/false, or use offscreen text to indicate the role
> and state, both of which work reliably.
>
> You can see an example of this at
> http://whatsock.com/tsg/Coding%20Arena/Accordions/Accordion%20(Interna
> l%20Content)/demo.htm
>
> Personally I'm not a fan of making an accordion have only one tab
> stop, because it doesn't make any sense from a usability perspective.
> For example,
>
> if the accordion includes form fields, you have to shift+tab all the
> way back to the accordion in order to arrow to the next accordion
> node, in order
>
> to begin the whole process over after expanding that node. It makes
> more sense to simply keep the standard tab order of native active
> elements, and just tab through the active elements of an accordion
> panel, then when you reach the next accordion link, to either choose
> to expand that node or continue past it.
>
> It doesn't have to be complicated.
>
>
>
>
>
>
>
> ----- Original Message -----
> From: "Alastair Campbell" < <EMAIL REMOVED> >
> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
> Sent: Thursday, August 01, 2013 9:09 AM
> Subject: Re: [WebAIM] building accessible javascript accordions?
>
>
>> Paul J. Adam wrote:
>>> There's no WCAG requirement that says you have to follow certain
>>> keyboard
>>>
>>> interactions for your
>>> ARIA widgets right?
>>
>> Personally I agree, but others believe that creating 'non standard'
>> implementations (according to the design patterns) will create more
>> confusion long term:
>> http://webaim.org/discussion/mail_thread?threadY14
>>
>> I'm hoping we can get to some agreement about what to do for
>> non-application sites that use interactive features that benefit from
>> ARIA.
>>
>> At the moment the best suggestion has been to include instructions at
>> the beginning of the widget, but I've had a hard time getting dev
>> teams to accept that, it looks hacky.
>>
>> Perhaps we need a set of design patterns for non-application use of
>> ARIA attributes? For use in specific cases where it does not clash
>> with the application version.
>>
>> -Alastair
>> >> >> list messages to <EMAIL REMOVED>
>
> > > list messages to <EMAIL REMOVED>
>