E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 13 (In chronological order)

From: Thad C
Date: Sat, Apr 25 2015 10:10PM
Subject: Examples for Implementing Accessible Hide/Show Panels
No previous message | Next message →

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

From: Thad C
Date: Sun, Apr 26 2015 8:11AM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

Question answered. Thanks!

On Sat, Apr 25, 2015 at 9:10 PM, Thad C < = EMAIL ADDRESS 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
>

From: Howard Kramer
Date: Sun, Apr 26 2015 10:55AM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

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 ADDRESS REMOVED = > wrote:

> Question answered. Thanks!
>
> On Sat, Apr 25, 2015 at 9:10 PM, Thad C < = EMAIL ADDRESS 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
> >
> > > > >



--
Howard Kramer
Conference Coordinator
Accessing Higher Ground
303-492-8672
cell: 720-351-8668

AHEAD Association of Higher Education and Disability

From: Birkir R. Gunnarsson
Date: Sun, Apr 26 2015 3:18PM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

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-tabless-multiselect-accordion
Cheers



On 4/26/15, Howard Kramer < = EMAIL ADDRESS 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 ADDRESS REMOVED = > wrote:
>
>> Question answered. Thanks!
>>
>> On Sat, Apr 25, 2015 at 9:10 PM, Thad C < = EMAIL ADDRESS 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
>> >
>> >> >> >> >>
>
>
>
> --
> Howard Kramer
> Conference Coordinator
> Accessing Higher Ground
> 303-492-8672
> cell: 720-351-8668
>
> AHEAD Association of Higher Education and Disability
> > > > >


--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Sun, Apr 26 2015 7:58PM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

Another example is available at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/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.

From: Thad C
Date: Mon, Apr 27 2015 6:02PM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

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 ADDRESS REMOVED = > wrote:

> Another example is available at
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Accordions/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.
>
>

From: Bryan Garaventa
Date: Mon, Apr 27 2015 6:56PM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

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

From: Steve Faulkner
Date: Tue, Apr 28 2015 1:19AM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

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-control/

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 ADDRESS 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
> > > > >

From: Heidi Valles
Date: Mon, May 11 2015 1:53PM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

Bryan,

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.

Thanks!
heidi




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

> 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-control/
>
> 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 ADDRESS 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
> > > > > > > > > >
> > > > >



--
Arch Inclusive
http://archinclusive.com

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

From: Bryan Garaventa
Date: Mon, May 11 2015 4:18PM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

Hi,
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:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
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.

:)

From: Jonathan Avila
Date: Tue, May 12 2015 6:35AM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

[Heidi wrote]
> I generally don't like the idea of moving focus automatically, but in this case it seems helpful.

In this case the button press is user initiated so it's not really happening automatically without the user being aware.

> 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.

If the user were closing a panel the focus should definitely not move.

> Also, I think moving focus might skip the "expanded" feedback from the button?

If the user is on an expandable buttons and presses enter and is moved to somewhere else the user would expect that they likely were moved to the expanded content. So the missing feedback would not be an obstacle IMO.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Heidi Valles
Date: Tue, May 12 2015 10:18AM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | Next message →

Thank you Bryan and Jonathan!

It sounds like moving focus to a newly opened panel might not be as
disorienting as I thought, and maybe even somewhat expected. Also makes
sense that moving focus is itself the implicit indicator that a panel has
expanded. In the case I'm dealing with now, it would be moving focus to an
iframe at the top of the page.

Thanks for the input!

best,
Heidi


On Tue, May 12, 2015 at 8:35 AM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> [Heidi wrote]
> > I generally don't like the idea of moving focus automatically, but in
> this case it seems helpful.
>
> In this case the button press is user initiated so it's not really
> happening automatically without the user being aware.
>
> > 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.
>
> If the user were closing a panel the focus should definitely not move.
>
> > Also, I think moving focus might skip the "expanded" feedback from the
> button?
>
> If the user is on an expandable buttons and presses enter and is moved to
> somewhere else the user would expect that they likely were moved to the
> expanded content. So the missing feedback would not be an obstacle IMO.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>

From: David Farough
Date: Tue, May 12 2015 12:18PM
Subject: Re: Examples for Implementing Accessible Hide/Show Panels
← Previous message | No next message

so the only thing that you need to do is insure that focus goes back to
the button that opened the panel. when the panel is closed.


David Farough
(819) 420-8418




Ce courriel est destiné exclusivement au destinataire mentionné en titre
et peut contenir de l'information privilégiée, confidentielle ou
soustraite à la communication aux termes des lois applicables. Toute
divulgation non autorisée, toute reproduction ou réacheminement est
interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
par erreur, veuillez le mentionner immédiatement à l'expéditeur et
supprimer le courriel et les copies.

This e-mail message is intended for the named recipient(s) and may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law. Unauthorized disclosure, copying or
re-transmission is prohibited. If you are not a named recipient or not
authorized by the named recipient(s), or if you have received this
e-mail in error, then please notify the sender immediately and delete
the message and any copies.