WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: VoiceOver and menus


From: Mark Magennis
Date: Aug 25, 2022 7:21AM

Birkir you said "I never try to interact with menus in browse mode, you're technically speaking not meant to do that". This is the salient point. I'll bet plenty of users do do that. It's never occurred to me before because I've never done user testing with MacOS/VoiceOver but since it doesn't have a non-browse mode it would seem natural for users to use browse commands any time, even within a menu. It sounds like the users just need to realise that isn't appropriate. I haven't yet investigated many menus but I would strongly expect them to remain open which might cause confusion later. This seems like a user awareness issue that applications can't be expected to remediate.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Birkir R. Gunnarsson
Sent: Thursday 25 August 2022 13:33
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: [EXTERNAL] 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.