Community
Participate
Working Groups
The "File, Edit, View, Tools" menu bar needs accessibility work in order to work with screen readers. This involves adding ARIA attributes such as: role="menubar", role="menu", role="menuitem", aria-haspopup="true", aria-labelledby="menuid", and aria-expanded="true/false". (also possibly role="menuitemcheckbox", role="menuitemradio", and aria-checked="true/false"). Also, the keyboard interaction isn't quite correct for a menubar. The user should be able to traverse the menus in the menu bar with left/right arrows (they currently need to use tab, which should actually just enter/exit the menubar), and they should be able to activate items with space or enter (they currently can only use enter). For info, the following example works with screen readers, and it has the correct keyboard behavior: http://www.oaa-accessibility.org/examplep/menubar1/ (although it is not perfect - for some reason NVDA thinks that all menus are submenus - not sure if this is an NVDA bug or a problem with the markup). Ideally, we would switch to using HTML5.1 <menu> / <menuitem> tags, however these are unfortunately not yet supported in the browsers (except for context menu in Firefox) and who knows when screen reader support will follow. Here is an example of <menu> / <menuitem> markup from the draft spec. For now, I hope we can use <ul> for <menu> and <button> for <menuitem>, and add appropriate ARIA attributes and behavior. <menu> <li> <button type=menu value="File" menu="filemenu"> <menu id="filemenu" type="popup"> <menuitem onclick="fnew()" label="New..."> <menuitem onclick="fopen()" label="Open..."> <menuitem onclick="fsave()" label="Save"> <menuitem onclick="fsaveas()" label="Save as..."> </menu> </li> <li> <button type=menu value="Edit" menu="editmenu"> <menu id="editmenu" type="popup"> <menuitem onclick="ecopy()" label="Copy"> <menuitem onclick="ecut()" label="Cut"> <menuitem onclick="epaste()" label="Paste"> </menu> </li> <li> <button type=menu value="Help" menu="helpmenu"> <menu id="helpmenu" type="popup"> <menuitem onclick="location='help.html'" label="Help"> <menuitem onclick="location='about.html'" label="About"> </menu> </li> </menu>
Current behavior is as follows. Keyboard: - tab through menu bar items. - arrow keys don't work in menu bar. Should be able to traverse through menu bar items with left/right arrow keys, and should be able to drop down menus with up/down arrow keys. - once a menu is open (using space or enter), arrow keys do work in menus. Up/down arrows navigate up/down in menu, and right arrow opens a submenu. Should cycle to top when down arrow past bottom item, and vice-versa. - Esc or left arrow closes current menu or submenu. - typing the first letter of a menu item does nothing. - user can tab through the menu and out the other side. The style changes that happen with arrow keys in menu do not happen with tab key. Screen reader (NVDA and JAWS on FF): - focus on File - NVDA says list with 1 item File button. JAWS says File button. Need role="menu". - drop down File menu - JAWS says listbox, to move to an item press the arrow keys. - type down arrow - JAWS says nothing. NVDA navigates to the keyboard shortcut column and next down arrow navigates to next item. Need to check dom order - may need aria-owns="list-id". - if use tab key to move to menu items, JAWS does read them. May need to set tabindex="-1" and then only set tabindex="0" for current item, or maybe use aria-activedescendant="current-menuitem-id". - screen readers don't recognize submenu. Need aria-haspopup="true" for submenus.
Here's the recommended keyboard and aria advice for menu bar and menu: https://www.w3.org/TR/wai-aria-practices-1.1/#menu
This is probably useful: https://www.w3.org/WAI/tutorials/menus/application/
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html
Reopening. Ideally, this work should be done as part of Bug 457886 and Bug 496678. But if the menu simplification is not going to go in soon, then this accessibility work needs to be done separately.
Car, thanks for the info. I"m just starting work on this now using the 'active Descendant' pattern. I'll update the menus / items with the appropriate ARIA etc...
Awesome! Just to make sure you have the latest guidance: http://w3c.github.io/aria-practices/#menu Thanks!
OK, making progress on this under the 'emoffatt/MenuBarUI' branch (unpushed as yet). We've succeeded in moving the File/Edit/View/Tools menus under a new 'menubar' element and fixing up the rendering. This is necessary in order to support the arrow keys in the menubar itself. I'm currently trying to make sure that the necessary aria is in place in all of our menu's structure (necessary because the key management should be based on the aria rather than our classList as we do currently.
GitHub Pull Request 52 created by [emoffatt] https://github.com/eclipse/orion.client/pull/52
I've just pushed the initial code for this to branch 'emoffatt/MenuBarUI'...
The code to support this has been released. Now a TAB will only get you to the 'File' menu item. From there you can use the arrow / enter keys to navigate the menu's structure. At any time a TAB will go beyond the menu bar directly to the runbar.
