WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: VoiceOver and menus

for

From: David Farough
Date: Aug 25, 2022 7:20AM


Hi Birkir;
I was looking at the ARIA example for menubar and noticed that Jaws was not indicating a submenu when appropriate. Is this a known issue for Jaws?
I am using the current version of Jaws.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, August 25, 2022 8:33 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] VoiceOver and menus

How does it behave with the ARIA Authoring Practices Menu or Manu Button examples?
I'd start with that as a baseline (as it should be coded fully to spec).
The question is bascially what event is fired by Safari when you use the navigate to next element command.
A properly coded menu listens for arrow key presses specifically and should implement them to navigate within the menu.
The tab key should close the menu (without making a selection) and move to the next focusable element, so if the navigate to next element action simulates the behavior of the tab key that is what should happen.
I never try to interact with menus in browse mode, you're technically speaking not ment to do that, after all the screen reader intercepts the key strokes so the author of the menu cannot control the behavior.


On 8/25/22, Mark Magennis < <EMAIL REMOVED> > wrote:
> I have a question about how MacOS/VoiceOver works within menus. Or
> really any screen reader which is not in an application mode with any
> widget that has its own keyboard operations. Suppose you have an ARIA
> menu. When it opens you use the up/down arrow keys to navigate between
> options. In JAWS and NVDA, you will be in application/forms mode (by
> default) so you can't use the up/down arrow keys for the browse
> command "read next element" unless you exit application mode. In
> VoiceOver you are never in an application mode so the VO+Right Arrow
> "read next element" command is always available. My question is, if
> you issue the "read next element" command, what should logically
> happen? Should it move the selection within the menu? Should it close the menu and read the next element after the menu? Something else?
>
> I've tried this in menus within the application I'm working on. In one
> case it reads the next element after the menu but leaves the menu open
> and in another case it activates the currently selected menu option,
> which is obviously wrong.
>
> If it should close the menu and move on to the next element, how can
> this be done? Presumably you'd need an event listener for the "read next element"
> keypress, in which case logically you'd need event listeners for every
> other possible browse action. That's obviously not a sensible approach.
>
> Anything insightful anyone can say about this would be welcome.
>
> Thanks,
> Mark
>
> Mark Magennis (he/him)
> Senior Accessibility Specialist
> Skillsoft | mobile: +353 87 60 60 162
> [cid:image001.jpg@01D8B87D.F7272470]<http://www.skillsoft.com/>;
>
>


--
Work hard. Have fun. Make history.