WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: building accessible javascript accordions?

for

From: Bryan Garaventa
Date: Aug 1, 2013 4:36PM

I agree that Tabs have a similar concept, at least as far as expanding and
collapsing goes, but there are differences. For instance, a group of Tabs
should be grouped together and share an insertion point, or at least have
the insertion points be adjacent to the Tab group of triggering elements,
such as directly after.

E.G

*Group of tab links*
*Insertion point container*

As opposed to an Accordion where insertion points are inline with the
triggering element.

E.G

*Accordion link one*
*Accordion one content container*
*Accordion link two*
*Accordion two content container*

The first makes more sense with one tab stop, because you can make your
selection then press tab to navigate directly into your desired content.

The second does not, because you are using the native DOM order to control
the focus movement in a logical manner between each section.


----- Original Message -----
From: "Alastair Campbell" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Thursday, August 01, 2013 2:22 PM
Subject: Re: [WebAIM] building accessible javascript accordions?


> Bryan Garaventa wrote:
>> 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.
>
> Thanks, that makes sense.
>
>
>> 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.
>
> Agree, but for a regular user I would apply the same logic to tabs as
> well though. You know the difference, but what signals the change of
> model for a regular user?
>
> Cheers,
>
> -Alastair
> > >