WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: VoiceOver and menus

for

From: Birkir R. Gunnarsson
Date: Aug 25, 2022 6:33AM

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.