E-mail List Archives

Re: Examples for Implementing Accessible Hide/Show Panels

for

From: Bryan Garaventa
Date: Apr 27, 2015 6:56PM


No problem, I'm always happy to help.

> - Use aria-expanded on the button that controls the display/hide of the panel

Yes, this works on both buttons and links, whether native or using role=button or role=link, then toggled accordingly. When using native buttons and links, an onClick can be used for both mouse and keyboard support, but if using a simulated element like a Div or Span, then an onClick and key event must be used to handle both mouse and the pressing of Enter so that both do the same thing. It's important to note that an onClick must be used, not onMouseUp/Down, which won't always be triggered reliably across ATs and devices. More info about this is available at
http://whatsock.com/training/#hd31

> - Do not explicitly set focus on any one item in the open panel

In this case, it's most useful just to keep focus on the toggle and let the user go from there after activating it.

> - Use aria-controls to associate the button with the panel. I don't believe you mentioned this in the thread but I do see it in the example in your second response.

Whenever aria-expanded is used, it's generally a good practice to specify what it controls using aria-controls. Some ATs use this to provide additional functionality and feedback to users.

Also, surrounding the toggle control with a heading is useful too, since it provides a quick mechanism for grouping related content and maintaining a well-structured document order. When it's not possible to use standard H# elements for this, role=heading + aria-level can be used on the parent container element instead. Such headings should never be used as the focusable triggering elements however.

All the best,
Bryan

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Thad C
Sent: Monday, April 27, 2015 5:03 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Examples for Implementing Accessible Hide/Show Panels

Thanks Bryan,

I have read your advise on past threads and you always have well thought out and well educated comments. Just to simplify the conversation, is it safe to say that if you have to use an accordion implementation for example it already exists and you need to make it accessible then you would advise the following:

- Use aria-expanded on the button that controls the display/hide of the panel
- Do not explicitly set focus on any one item in the open panel
- Use aria-controls to associate the button with the panel. I don't believe you mentioned this in the thread but I do see it in the example in your second response.

Thanks for your great advise.



On Sun, Apr 26, 2015 at 6:58 PM, Bryan Garaventa < <EMAIL REMOVED> > wrote:

> Another example is available at
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordi
> ons/ARIA%20Accordion%20(Internal%20Content)/demo2.htm
>
> One thing to keep in mind, it's a flawed paradigm to have only one tab
> stop for an accordion control, because the content is rendered inline
> with the triggering element. This causes major accessibility issues
> for keyboard only users when expanded accordion panels include many
> active elements, since it is then impossible to maintain a contiguous
> tab order that matches the reading order of the page.
>
> Also, accordions are simple control types, and should not need to
> enforce a particular mode of navigation for users such as Applications
> Mode, which is confusing when all you want to do is just expand
> something and read the content. This is what happens when you use ARIA
> Tab markup on an accordion for example, which I don't agree with doing for this reason.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Sunday, April 26, 2015 2:18 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Examples for Implementing Accessible Hide/Show
> Panels
>
> The OAA examples work quite ok actually, though I do not necessarily
> agree 100% with the markup.
> aria-expanded should be on the buttons that control the display/hide
> of their associated panels rather than on the panels themselves.
> (keep in mind, if we do this, the name of the button .. in this case
> its value property, should not change, it should just be "topic 1" and
> aria-expanded should be updated to indicate visibility of the
> associated panel).
> Also I do not think the focus should move from the button to the panel
> it controls, especially not when the content is inline to the button
> (comes right after the button, in content order).
> You seem to be looking for an accessible accordion pattern (or a
> variant thereof).
> Simplest example can be found here:
> http://www.3needs.org/en/testing/code/aria-expanded.html
> An accordion example can be found e.g. at:
>
> https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-table
> ss-multiselect-accordion
> Cheers
>
>
>
> On 4/26/15, Howard Kramer < <EMAIL REMOVED> > wrote:
> > Hi Thad,
> >
> > What answer did you come up with? I didn't see it in your post. I've
> > been looking for an accessible accordion also.
> >
> > Thanks,
> > Howard
> >
> > On Sun, Apr 26, 2015 at 8:11 AM, Thad C
> > < <EMAIL REMOVED> >
> wrote:
> >
> >> Question answered. Thanks!
> >>
> >> On Sat, Apr 25, 2015 at 9:10 PM, Thad C
> >> < <EMAIL REMOVED> >
> >> wrote:
> >>
> >> > Greetings Group,
> >> >
> >> > I am looking for examples of accessible hide/show panels. The
> >> > following Open Ajax Alliance examples seem to illustrate the
> >> > functionality I am looking for:
> >> >
> >> > http://www.oaa-accessibility.org/examplep/hideshow1/
> >> >
> >> > In this example a user activates the "Hide Topic 1" button, the
> >> associated
> >> > panel is shown, focus goes to the associated panel however the
> >> > content inside *is not* read by assistive technology
> >> >
> >> > However if a user activates the "Hide Topic 2" button, the
> >> > associated panel is shown, focus goes to the associated panel and
> >> > the content
> >> inside*
> >> > is* read by assistive technology. This is the behavior I would
> >> > like to emulate. Can anyone give me a technical explanation of
> >> > why the "Hide
> >> Topic
> >> > 2" scenario reads the content inside the panel and the "Hide Topic 1"
> >> does
> >> > not?
> >> >
> >> > If anyone has other example of this functionality it would be
> >> > greatly appreciated as well
> >> >
> >> > Thanks for your help
> >> >
> >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >>
> >
> >
> >
> > --
> > Howard Kramer
> > Conference Coordinator
> > Accessing Higher Ground
> > 303-492-8672
> > cell: 720-351-8668
> >
> > AHEAD Association of Higher Education and Disability
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >