WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Examples for Implementing Accessible Hide/Show Panels


From: Bryan Garaventa
Date: May 11, 2015 4:18PM

There are cases where moving focus is helpful, though it depends on what you wish to show/hide and how it's rendered. For example I've seen some toggles open settings dialogs that are rendered at the end of the Body element, making it necessary to move focus into the new content in order to provide the correct keyboard navigation and focus control for screen reader users. In which case it's important to move focus back to the toggle after the dynamic content region closes.

In the case of an accordion, typically the content is rendered inline in the DOM, so this wouldn't be needed, and if the toggle controls were all grouped together vertically or horizontally with the dynamic region displayed outside the group then it would fit the Tab paradigm and then it would make sense to use the Tab keyboard model instead.

Animation effects such as floating a newly rendered panel in from the left/top/right/bottom wouldn't have any negative effect on the keyboard functionality if the newly displayed content still existed within the DOM at the same logical level of the toggle control, so in that case it wouldn't be useful, and actually may cause the screen to flicker and jerk about as focus is set to a panel that is still in motion. (This typically happens in IE)

In cases where an animation floats something in that doesn't appear inline in the DOM though, I've found that it helps to set focus to it after the animation settles rather than before.

It is true that if you move focus away from a toggle control before it's state changes then that state change won't be conveyed, but usually this isn't really a problem since the user is aware that a focus change has occurred anyway and they are now within the region they desired to open by activating it.

Here is a simple example of this using a date picker:
The trigger of which is technically a hide/show toggle that includes aria-expanded, even though focus moves into the date picker when activated.

So it really depends on what you need and how you are rendering the content. I'm sorry if that is vague, but markup and implementation variations are virtually infinite.


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Heidi Valles
Sent: Monday, May 11, 2015 12:54 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Examples for Implementing Accessible Hide/Show Panels


What are your thoughts on moving focus from the button to the panel if the panel does not immediately follow the toggle button? For example, a panel slides down from the top of the page.

I generally don't like the idea of moving focus automatically, but in this case it seems helpful. Though at the same time, not helpful if the user doesn't want to move into the panel contents, and just wishes to toggle-close and move on. Also, I think moving focus might skip the "expanded" feedback from the button?

I thought about a hidden "jump to panel" link that follows the toggle, but feel like it would be easily missed.


On Tue, Apr 28, 2015 at 3:19 AM, Steve Faulkner < <EMAIL REMOVED> >

> Bulletproof HTML5 <details> fallback using jQuery
> https://mathiasbynens.be/notes/html5-details-jquery
> disclosure-button custom control
> http://www.paciellogroup.com/blog/2014/05/disclosure-button-custom-con
> trol/
> HTML5 - details/summary demo
> http://codepen.io/stevef/pen/jiCBE
> HTML5 - details/summary polyfill example used in w3c specs
> http://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings
> --
> Regards
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> On 26 April 2015 at 05:10, 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
> > > >
> > > archives at http://webaim.org/discussion/archives
> >

Arch Inclusive

*Make your website work better, for more people.*