WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Looking for input on appropriate ARIA states for mobile navigation menu button

for

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

From: Marc Solomon
Date: Mon, May 02 2016 2:42PM
Subject: Looking for input on appropriate ARIA states for mobile navigation menu button
No previous message | Next message →

After reviewing the ARIA authoring practices for related widgets (e.g. menu button, menu, pop up menu) and a number of high profile accessibility focused websites, there seems to be a few different ways to handle the implementation. In my opinion, the element that triggers the navigation menu should have a role of button. I don't think I will get many arguments on this. I would also like to use aria-haspopup and aria-expanded to notify AT users of the widget's function and current state. What do you consider to be best practice from a usability perspective and does this differ from what is required from a WCAG standards perspective?

Thanks,
Marc

From: Bryan Garaventa
Date: Mon, May 02 2016 4:51PM
Subject: Re: Looking for input on appropriate ARIA states for mobile navigation menu button
← Previous message | Next message →

Hi, currently aria-haspopup is reserved for indicating popup Menus only.

We are currently in the process of extending this for different popup types for ARIA 1.1, but this isn't ready yet.

For indicating expanded dynamic content within the same page, aria-expanded will likely be most helpful on role=button.

It is also helpful in some cases to surround the dynamically displayed content in a landmark or named region for quicker navigation, such as on iOS using the rotor.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com


From: _mallory
Date: Tue, May 03 2016 2:27AM
Subject: Re: Looking for input on appropriate ARIA states for mobile navigation menu button
← Previous message | Next message →

On Mon, May 02, 2016 at 10:51:32PM +0000, Bryan Garaventa wrote:
> It is also helpful in some cases to surround the dynamically displayed content in a landmark or named region for quicker navigation, such as on iOS using the rotor.

Michiel Bijl did some modal-dialog tests and when he added
aria-labelledy and aria-describedby, it worked ok mostly
with JAWS, NVDA and Orca, but didn't work well in VO.
https://dir.rawr.eu/research/dialog/index.html

Would this be because he navigated using regular page navigation
and not the rotor? Would be good to know (I don't have a Mac).

_mallory

From: Birkir R. Gunnarsson
Date: Tue, May 03 2016 4:26AM
Subject: Re: Looking for input on appropriate ARIA states for mobile navigation menu button
← Previous message | Next message →

For menu construct on mobile I have used:

1. aria-expanded on the trigger element (a button is most appropriate,
a link will do the same though).
2. role="region and aria-labelledby="id of the trigger element" around
the list of links in that menu.
This has worked pretty well, once Voiceover decided to support
aria-expanded (iOS 8.4 update).


On 5/3/16, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
> On Mon, May 02, 2016 at 10:51:32PM +0000, Bryan Garaventa wrote:
>> It is also helpful in some cases to surround the dynamically displayed
>> content in a landmark or named region for quicker navigation, such as on
>> iOS using the rotor.
>
> Michiel Bijl did some modal-dialog tests and when he added
> aria-labelledy and aria-describedby, it worked ok mostly
> with JAWS, NVDA and Orca, but didn't work well in VO.
> https://dir.rawr.eu/research/dialog/index.html
>
> Would this be because he navigated using regular page navigation
> and not the rotor? Would be good to know (I don't have a Mac).
>
> _mallory
> > > > >


--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Tue, May 03 2016 11:11AM
Subject: Re: Looking for input on appropriate ARIA states for mobile navigation menu button
← Previous message | No next message

In the most recent updates of iOS using VO, support has been getting better, so more landmark information is conveyed. When you use the rotor, you can swipe up and down with one finger for example and quickly jump between the landmarks. This is quite helpful at times.


Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com