Activating menu items on webpages is needlessly complicated

[Simon818]

One of my favourite websites recently switched from a link-based sidebar to a bunch of submenus with menu items. The layout makes a lot of sense visually, and it's pretty fancy. One of the things I noticed when trying to browse it is the fact that I have to turn on focus mode to activate a menu item... for some reason. When I press enter on one, focus mode turns on, and I have to press enter again. It's almost easier to just tab through the site at this point. There may be reasoning for this, and it seems like something that would have been changed before now had it been a serious issue, but right now I'm finding it to be a major annoyance and am not sure why I can't just click on them like anything else.
There also doesn't seem to be a keyboard command to move to the next menu, or menu item. They seem to be more and more common on webpages, and right now I'm not finding a way to deal with them very well in NVDA. I'm just a user, so suggestions are of course, welcome.

[jcsteh]

Menus are supposed to be more like list boxes, tree views and the like; i.e. you interact with them primarily in focus mode, not browse mode. The website should provide its own menu-like keyboard navigation, which makes for a much more natural experience (e.g. right arrow would open a sub menu). Normally, something would set focus to a menu item and NVDA would automatically switch to focus mode. This case is problematic because the menu doesn't "pop up" and get focus; it's always there. I guess tabbing might focus the menu, but we don't really want to require tabbing here.

[Simon818]

I understand what you're saying. It seems as though you're giving the web developer way too much credit, since I see tons of instances where keyboard navigation is completely nonexistent, but I get the idea. It would still be really useful to have a simple way to click a menu item from browse mode, since keyboard navigation isn't guaranteed. I've informed the developers though, so hopefully something will be done in this specific case.

[jcsteh]

To be clear, this decision is not just us assuming an ideal world. The ARIA spec requires keyboard navigation to be implemented for such widgets. Totally hear you that many authors don't follow the spec, though.

[jcsteh]

Implementation note: I think we could do the same thing we do for radio buttons here; i.e. switch to focus mode if they get focus, but just activate them if you press enter from browse mode. That should allow us to keep a decent native keyboard navigation experience while improving things in browse mode.

P2 because we're focusing on ARIA fixes soonish.

[derekriemer]

Yes. This is also happening more on the web over time, and won't go away. I think this is a completely fair solution.

…

On 1/15/2017 10:18 PM, James Teh wrote: Implementation note: I think we could do the same thing we do for radio buttons here; i.e. switch to focus mode if they get focus, but just activate them if you press enter from browse mode. That should allow us to keep a decent native keyboard navigation experience while improving things in browse mode. P2 because we're focusing on ARIA fixes soonish. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6735 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivaSn0_Jlg5m9MmekMsLD5Rm1Doeqks5rSv2bgaJpZM4LkLG6>.

-- ------------------------------------------------------------------------ Derek Riemer * Department of computer science, third year undergraduate student. * Proud user of the NVDA screen reader. * Open source enthusiast. * Member of Bridge Cu * Avid skiier. Websites: Honors portfolio <http://derekriemer.com> Awesome little hand built weather app! <http://django.derekriemer.com/weather/> email me at derek.riemer@colorado.edu <mailto:derek.riemer@colorado.edu> Phone: (303) 906-2194

[LeonarddeR]

Looking forward to this. I recall bitbucket doing it the wrong way as well. N.B. Sent on behalf of @BabbageCom

…

Op 16 jan. 2017 om 06:18 heeft James Teh ***@***.***> het volgende geschreven: Implementation note: I think we could do the same thing we do for radio buttons here; i.e. switch to focus mode if they get focus, but just activate them if you press enter from browse mode. That should allow us to keep a decent native keyboard navigation experience while improving things in browse mode. P2 because we're focusing on ARIA fixes soonish. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jcsteh]

Hint to implementer: the relevant code is in browseMode.BrowseModeTreeInterceptor.shouldPassThrough. We basically want to treat all menu items (including radio menu items, etc.) the same way we do radio buttons.

[feerrenrut]

I think the following example demonstrates the described issue: http://oaa-accessibility.org/example/25/

[jcsteh]

This following (not at all realistic) example can be used for testing:

<button>Before</button>
<div tabindex="0" role="menuitem" onClick="alert('Gotcha');">Cheese</div>
<button>After</button>

1. Switching to browse mode then tabbing to the menu item should switch to focus mode. Currently works.
2. Switching to browse mode, cursoring to the menu item, then pressing enter should bring up the dialog. Currently doesn't work.

[LeonarddeR]

Are there more roles than just menuitem and radiomenuitem? How about popupmenu, for example? I'll probably send in a pr tomorrow. N.B. Sent on behalf of @BabbageCom

…

Op 18 jan. 2017 om 02:34 heeft James Teh ***@***.***> het volgende geschreven: This following (not at all realistic) example can be used for testing: <button>Before</button> <div tabindex="0" role="menuitem" onClick="alert('Gotcha');">Cheese</div> <button>After</button> Switching to browse mode then tabbing to the menu item should switch to focus mode. Currently works. Switching to browse mode, cursoring to the menu item, then pressing enter should bring up the dialog. Currently doesn't work. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[derekriemer]

Popup menu is for popup menus, not items I believe. It's the actual menu.

…

On Wed, Jan 18, 2017 at 1:45 PM, Leonard de Ruijter < ***@***.***> wrote: Are there more roles than just menuitem and radiomenuitem? How about popupmenu, for example? I'll probably send in a pr tomorrow. N.B. Sent on behalf of @BabbageCom > Op 18 jan. 2017 om 02:34 heeft James Teh ***@***.***> het volgende geschreven: > > This following (not at all realistic) example can be used for testing: > > <button>Before</button> > <div tabindex="0" role="menuitem" onClick="alert('Gotcha');"> Cheese</div> > <button>After</button> > Switching to browse mode then tabbing to the menu item should switch to focus mode. Currently works. > Switching to browse mode, cursoring to the menu item, then pressing enter should bring up the dialog. Currently doesn't work. > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6735 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFGivTBz4aRo31XXuF5aG0ph16PkrYuCks5rTnnigaJpZM4LkLG6> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[jcsteh]

This is assigned to @feerrenrut and he's already working on it. Thanks.