WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: building accessible javascript accordions?

for

From: Roger Hudson
Date: Aug 1, 2013 5:20PM

Very interesting discussion.

If a button (accordion) causes a section of a page to be displayed (or
hidden) should you advise a screen reader user that this is going to happen?
This would clearly seem to be a good idea, but I am curious to know where a
failure to provide this information would sit in WCAG 2.0. I can see how
knowing if something is selected or not (or expanded/collapsed) falls under
4.1.2, but what about providing advanced warning of this behaviour?

Thanks,

Roger

-----Original Message-----
From: Birkir R. Gunnarsson [mailto: <EMAIL REMOVED> ]
Sent: Friday, 2 August 2013 5:11 AM
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>
>
messages to <EMAIL REMOVED>