E-mail List Archives
Re: building accessible javascript accordions?
From: Birkir R. Gunnarsson
Date: Aug 1, 2013 1:11PM
- Next message: Chagnon | PubCom: "Digital signatures in PDFs"
- Previous message: John E Brandt: "Re: comprehensive list of keyboard accessible software?"
- Next message in Thread: Alastair Campbell: "Re: building accessible javascript accordions?"
- Previous message in Thread: Bryan Garaventa: "Re: building accessible javascript accordions?"
- View all messages in this Thread
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(Internal%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
>> >> >> >
> > > >
- Next message: Chagnon | PubCom: "Digital signatures in PDFs"
- Previous message: John E Brandt: "Re: comprehensive list of keyboard accessible software?"
- Next message in Thread: Alastair Campbell: "Re: building accessible javascript accordions?"
- Previous message in Thread: Bryan Garaventa: "Re: building accessible javascript accordions?"
- View all messages in this Thread