WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-expanded state for show-hide interaction?


From: Judith.A.Blankman@wellsfargo.com
Date: Nov 25, 2014 12:19PM

Thanks for the input, everyone.

Birkir, just to clarify, we have a show/hide component that on desktop is
presented vertically.

Here's an example:

This content hasn't been migrated to a smartphone interface yet, but other
pages have.

We also have pages with tabbed content. An example:

That content, when migrated to a mobile device, will be presented as a
show/hide component. There is also another layer of show/hide in the FAQ

I don't think we need to communicate the first set of show/hide (formerly
tab) content as a tabbed component on a mobile device. We do need to
communicate the fact that it expands/collapses to reveal more info.

I love the idea of keeping it simple and using Steve and Jonanthan's
recommendations for using aria-expanded.

I'll pass this on to the development team, unless there are operating
systems/devices that require more, like perhaps older ones?


On 11/23/14 2:37 PM, "Birkir R. Gunnarsson" < <EMAIL REMOVED> >

>Thanks Bryan
>I was misinterpreting this feature.
>I thought that aria-hidden only overrode the container element, not
>its children.
><div aria-hidden="false" style="display: none;">
>Some content, this is all visible to screen readers, but invisible to
>the rest of the world.
><a href="http://www.blinconspiracy.com"Take over the world</a>
>but if you explicitly declare a child of the container as hidden that
>would override the semantics of the parent
><div aria-hidden="false" style="display: none;">
>Some content, this is all visible to screen readers.
><a href="http://www.blinconspiracy.com"Take over the world</a>
><input type="hidden" value="AlreadyDone"> <!-- this should be hidden
>still, I thought -->
>I see from the context that my understanding is probably not true.
>I think this opens the door to a lot of confusion, but that is
>discussion for another area.
>Thanks for clearing this up!
>On 11/23/14, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>> Just as a quick note about aria-hidden=false and VoiceOver, this is
>> a feature, so it's likely to become more widely
>> implemented in the future.
>> Reference: http://lnkd.in/bA8ZaPP
>> And
>> http://www.w3.org/2013/12/16-pf-minutes.html
>> -----Original Message-----
>> [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R.
>> Gunnarsson
>> Sent: Sunday, November 23, 2014 10:55 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] aria-expanded state for show-hide interaction?
>> Judith
>> What you are describing is a typical tabbed interface (at least in the
>> standard world of desktop).
>> For tabs one needs to have a few things in mind:
>> 1. The list container around the available tabs should have an ARIA
>>role of
>> "tablist".
>> 2. Links that one clicks to update the content have a role of "tab"
>> - have aria-controls pointing to the id of the content that is
>>displayed or
>> hidden
>> - the active tab (tab that controls the visible content) should have
>> aria-selected="true" (this must be updated dynamically via
>> Javascript so that only one tab is selected at any one time and that is
>> tab associated with the visible content).
>> 3. The container for the actual content should have a role of tabpanel
>> aria-labelledby pointing to the active tab (same tab that
>> has aria-selected="true" and aria-controls pointing to the container
>> 4. using CSS display techniques is enough to show/hide content for all
>> (as long as you hide CSS using display: none or
>> visibility:
>> hidden to hide it). Using aria-hidden can be done but it has bugs with
>> e.g. on Voiceover. If the container has
>> aria-hidden="false" but there is a component inside hidden by other
>> Voiceover (at least in version 8.1) will not respect
>> this, and will announce the component.
>> <div aria-hidden="false">
>> <input type="hidden" id="x" value="default input value"> ..
>> </div>
>> .. Voiceover will announce the hidden input as user swipes through the
>> content.
>> The following code mock up (tab 2 is active) <div role="tablist"> <a
>> href="javascript to show hide" id=tab1" role="tab"
>> aria-controls="content1">Tab 1</a>
>> <a href="javascript to show hide" id=tab2" role="tab"
>> aria-controls="content2" aria-selected="true">Tab 2</a> </div> <div
>> id="content1" role="tabpanel" aria-labelledby="tab1"
>> style="display: none;">
>> ...
>> </div>
>> <div id="content2" role="tabpanel" aria-labelledby="tab2"> You can see
>> content!!!
>> </div>
>> Note: you can use one container for all the tabs, and just populat it
>> the appropriate content when the associated tab is
>> activated.
>> Examples:
>> Marco Zehe:
>> http://www.marcozehe.de/2013/02/02/advanced-aria-tip-1-tabs-in-web-apps/
>> (www.whatsock.com also has great examples and articles).
>> I know that a fully tabbed interface may not work very well for mobile,
>> one can do a much simpler version.
>> Each link that expands or collapses a section should have aria-expanded
>> attribute, set to "true" when content is visible and "false"
>> if it is hidden.
>> Note: compliment aria-expanded attributes on links with the title
>> of the link to say "expanded" when visible and
>> "collapsed"
>> when hidden. In your case the title of the active link should just say
>> "selected" since only one tab can be active.
>> Voiceover prior to version 8 did not announce aria-expanded attributes
>> all.
>> Voiceover 8 and above announces aria-expanded incorrectly
>> - says "collapsed" when aria-expanded="true" and
>> - "expanded" when aria-expanded = false).
>> I mention this because you said you are creating a mobile component
>> specifically, so Voiceover support is essential for any
>> accessible component targeted at mobile.
>> code
>> <a href="javascript" aria-expanded="true" title="selected">Tab 1</a>
>> id="tab1"> Visible content </div> <a href="Javascript"
>> aria-expanded="false">Tab 2 </a> <div tab2 style="display: none;"> ...
>> </div>
>> Sure you can nest the links in list items.
>> But you can never map an actionable component to a listitem, heading or
>> other non-interactive aria role.
>> Users do not expect to be able to activate a list item.
>> so this is ok
>> <ul
>> <li><a href=...">Tab 1</a></li>
>> </ul>
>> but this is not
>> <a role="listitem" href="x">Tab 1</a>
>> Cheers
>> -B
>> On 11/21/14, <EMAIL REMOVED>
>> < <EMAIL REMOVED> > wrote:
>>> I'm working on specifications for a hard coded component for a
>>> smartphone interface. I won't be doing the coding, I just need to
>>> help our designers point developers in the right direction.
>>> * There are 6 links in a list, visually formatted like a bar with
>>> icon and text
>>> * The entire bar and its contents is tappable
>>> * Tapping the bar expands or collapses a container that displays
>>> brief content
>>> * Only one content area is open at any one time
>>> * If a section is open and someone taps on another section, the
>>> section
>>> that was open closes
>>> I assume we should include some hidden text ("expand") associated with
>>> the visible link text to indicate that the link expands to reveal the
>>> content when it's closed, and vice versa.
>>> Is the state aria-hidden (true or false) for the container sufficient
>>> to indicate that the section is collapsed or expanded?
>>> Or should we also use the state aria-expanded (true or false) and
>>> apply it to <li> tags that would have a role="listitem"?
>>> I'm looking at this WAI-ARIA page for guidance
>>> http://www.w3.org/TR/wai-aria/states_and_properties#aria-expanded
>>> Thanks!
>>> Judith Blankman
>>> Accessibility Strategist
>>> Customer Experience
>>> Wells Fargo Digital Channels Group | 550 California Street, 2nd
>>> floor | San Francisco, CA 94104
>>> MAC A0122-020
>>> Tel 415-947-6583 | Cell 415-601-1114 | Fax 415-974-7452
>>> >>> >>> list messages to <EMAIL REMOVED>
>> --
>> Work hard. Have fun. Make history.
>> >> >> messages to <EMAIL REMOVED>
>> >> >> >>
>Work hard. Have fun. Make history.