E-mail List Archives
Thread: VoiceOver and menus
Number of posts in this thread: 6 (In chronological order)
From: Mark Magennis
Date: Wed, Aug 24 2022 4:47AM
Subject: VoiceOver and menus
No previous message | Next message →
I have a question about how MacOS/VoiceOver works within menus. Or really a=
ny screen reader which is not in an application mode. Suppose you have an A=
RIA 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 defaul=
t) so you can't use the up/down arrow keys for the browse command "read nex=
t 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 al=
ways available. My question is, if you issue the "read next element" comman=
d, what should logically happen? Should it move the selection within the me=
nu? Should it close the menu and read the next element after the menu? Some=
thing 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 a=
nother case it activates the currently selected menu option, which is obvio=
usly wrong.
If it should close the menu and move on to the next element, how can this b=
e 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 oth=
er 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
www.skillsoft.com<;http://www.skillsoft.com/>;
[cid:image001.jpg@01D8B7AE.9E7A5740]<http://www.skillsoft.com/>;
From: Mark Magennis
Date: Thu, Aug 25 2022 5:26AM
Subject: Re: VoiceOver and menus
← Previous message | Next message →
I have a question about how MacOS/VoiceOver works within menus. Or really a=
ny screen reader which is not in an application mode with any widget that h=
as its own keyboard operations. Suppose you have an ARIA menu. When it open=
s you use the up/down arrow keys to navigate between options. In JAWS and N=
VDA, you will be in application/forms mode (by default) so you can't use th=
e 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 que=
stion is, if you issue the "read next element" command, what should logical=
ly happen? Should it move the selection within the menu? Should it close th=
e 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 a=
nother case it activates the currently selected menu option, which is obvio=
usly wrong.
If it should close the menu and move on to the next element, how can this b=
e 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 oth=
er 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/>;
From: Birkir R. Gunnarsson
Date: Thu, Aug 25 2022 6:33AM
Subject: Re: VoiceOver and menus
← Previous message | Next message →
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 ADDRESS 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.
From: David Farough
Date: Thu, Aug 25 2022 7:20AM
Subject: Re: VoiceOver and menus
← Previous message | Next message →
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.
From: Mark Magennis
Date: Thu, Aug 25 2022 7:21AM
Subject: Re: VoiceOver and menus
← Previous message | Next message →
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.
From: David Farough
Date: Thu, Aug 25 2022 8:45AM
Subject: Re: VoiceOver and menus
← Previous message | No next message
I found the followig github issue on the Jaws Standards support site:
https://github.com/FreedomScientific/VFO-standards-support/issues/415
Using these menus will be confusing for Jaws users since the presence of submenus is not indicated.