E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

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

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

From: Judith.A.Blankman
Date: Fri, Nov 21 2014 4:51PM
Subject: aria-expanded state for show-hide interaction?
No previous message | Next message →

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 an icon and text
* The entire bar and its contents is tappable
* Tapping the bar expands or collapses a container that displays some 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

= EMAIL ADDRESS REMOVED =

From: Birkir R. Gunnarsson
Date: Sun, Nov 23 2014 11:54AM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

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 the tab
associated with the visible content).
3. The container for the actual content should have a role of tabpanel
and aria-labelledby pointing to the active tab (same tab that has
aria-selected="true" and aria-controls pointing to the container id).
4. using CSS display techniques is enough to show/hide content for all
users (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
it e.g. on Voiceover. If the container has aria-hidden="false" but
there is a component inside hidden by other means, 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 this content!!!
</div>

Note: you can use one container for all the tabs, and just populat it
with 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, so 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
attribute 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 at 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>
<div 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 any 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 ADDRESS REMOVED =
< = EMAIL ADDRESS 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 an
> icon and text
> * The entire bar and its contents is tappable
> * Tapping the bar expands or collapses a container that displays some
> 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
>
>
> = EMAIL ADDRESS REMOVED =
>
>
>
>
> > > >

--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Sun, Nov 23 2014 2:35PM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

Just as a quick note about aria-hidden=false and VoiceOver, this is actually 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

From: Birkir R. Gunnarsson
Date: Sun, Nov 23 2014 3:37PM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

Thanks Bryan

I was misinterpreting this feature.
I thought that aria-hidden only overrode the container element, not
its children.
so
<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>
</div>

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"> 
</div>

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!
-B

On 11/23/14, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> Just as a quick note about aria-hidden=false and VoiceOver, this is actually
> 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
>
>
>
>

From: Mallory van Achterberg
Date: Mon, Nov 24 2014 4:24AM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

On Sun, Nov 23, 2014 at 05:37:48PM -0500, Birkir R. Gunnarsson wrote:
> <input type="hidden" value="AlreadyDone"> 

I thought so as well. Type=hidden is supposed to always be hidden,
from all user agent users, at all times. That was the point of the
type, I thought.

Would be an issue if some users, due to some author's misuse of
aria-hidden, would start seeing CSRF tokens and other submitty
information.

_mallory

From: Jonathan Avila
Date: Mon, Nov 24 2014 5:25AM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

I would apply the aria-expanded to the items that trigger the items to show or hide. - from your description this sounds like the list items. Using aria-expanded = true or false will let the screen reader user know that the item is expandable without requiring additional text.

Jon

> On Nov 21, 2014, at 6:55 PM, " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS 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 an icon and text
> * The entire bar and its contents is tappable
> * Tapping the bar expands or collapses a container that displays some 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
>
>
> = EMAIL ADDRESS REMOVED =
>
>
>
>
> > >

From: Steve Faulkner
Date: Mon, Nov 24 2014 5:31AM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

On 24 November 2014 at 12:25, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> I would apply the aria-expanded to the items that trigger the items to
> show or hide. - from your description this sounds like the list items.
> Using aria-expanded = true or false will let the screen reader user know
> that the item is expandable without requiring additional text.

+1

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;

From: Judith.A.Blankman
Date: Tue, Nov 25 2014 12:19PM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

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:
https://www.wellsfargo.com/privacy-security/fraud/protect/fraud-tips/

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

We also have pages with tabbed content. An example:
https://www.wellsfargo.com/credit-cards/rewards/

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

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?

Judith

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

>Thanks Bryan
>
>I was misinterpreting this feature.
>I thought that aria-hidden only overrode the container element, not
>its children.
>so
><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>
></div>
>
>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"> 
></div>
>
>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!
>-B
>
>
>
>On 11/23/14, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
>> Just as a quick note about aria-hidden=false and VoiceOver, this is
>>actually
>> 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
>>
>>
>>
>>

From: Birkir R. Gunnarsson
Date: Tue, Nov 25 2014 12:52PM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | Next message →

Judith

Sounds great.
Just remember my point regarding a complementary title on the
component that expands and collapses accordions. aria-expanded support
is still problematic on mobile devices and users will need the
additional title element, at least in the short term.

<a title)"click to open" aria-expanded="false">Peronal info</a>

<a title)"click to close" aria-expanded="true">Peronal info</a>

On 11/25/14, = EMAIL ADDRESS REMOVED =
< = EMAIL ADDRESS REMOVED = > wrote:
> 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:
> https://www.wellsfargo.com/privacy-security/fraud/protect/fraud-tips/
>
> This content hasn't been migrated to a smartphone interface yet, but other
> pages have.
>
> We also have pages with tabbed content. An example:
> https://www.wellsfargo.com/credit-cards/rewards/
>
> 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
> "tab."
>
> 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?
>
> Judith
>
> On 11/23/14 2:37 PM, "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>>Thanks Bryan
>>
>>I was misinterpreting this feature.
>>I thought that aria-hidden only overrode the container element, not
>>its children.
>>so
>><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>
>></div>
>>
>>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"> 
>></div>
>>
>>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!
>>-B
>>
>>
>>
>>On 11/23/14, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
>>> Just as a quick note about aria-hidden=false and VoiceOver, this is
>>>actually
>>> 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
>>>
>>>
>>>
>>>

From: Joe Chidzik
Date: Wed, Nov 26 2014 1:16AM
Subject: Re: aria-expanded state for show-hide interaction?
← Previous message | No next message

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

Hi Judith,

You raise a good point here regarding older devices. Afaik, whilst the aria-expanded attribute has good general support across mobile environments, it is not supported in iOS 7 (and older) (http://pauljadam.com/demos/ariasupport.html).

Using hidden (off-screen is one option) text to indicate the state is one option. This would create some duplication for user-agentsscreenreaders that do support aria-expanded - they would hear both - however you could use different text for the hidden text e.g. "show details" "hide details" to offset this issue.

So for a component like

<button aria-expanded="false">Mortgages<span class="element-invisible"> Show details</span></button>
<div>
<p>Contents here</p>
</div>

This would be announced by screenreaders that support aria-expanded as "Button collapsed Mortgages. Show details" - they would read both the hidden text and the aria-expanded state.

For iOS 7 devices, this should (I've not got a device handy to test) just read the hidden text e.g. "Button mortgages. Show details" which still conveys the button functionality. When expanded, the hidden text would need to be amended e.g.

<button aria-expanded="true">Credit cards<span class="element-invisible"> Hide details</span></button>
<div>
<p>Contents here</p>
</div>

An iOS7 device should read this as . "Button mortgages. Hide details"; again, the button functionality is conveyed to the user.

I'm sure there are other ways to address this issue as well, but this is one option.

Joe