Menu Behavior and Implementation

Below is a proposal for keyboard and mouse behaviors for a menu component. 
 I have a few questions about the ARIA implementation. 

1) Set Focus to menu item on mouse over or use ARIA state = selected? 
 When navigating with the keyboard it is important to set focus to the 
menu items so they will be spoken by a screen reader.   However, when 
using the mouse to navigate the menus shoud the menu item which the mouse 
is over receive focus or should it just be marked with a selected state? I 
was thinking that the items should also get focus when the user is 
navigating via the mouse. This makes it easier to implement  the code to 
support switching between mouse and keyboard navigation.  It will also 
insure that if a screen reader is being used in conjunction with the mouse 
that the menu item information will be spoken.   In a windows client 
application menus have somewhat of a special state (almost like another 
window)  and the items do get focus when the user hovers above them with 
the mouse. 

2) Should the first item of the menu bar only be in the tab order or 
should there also be a keystroke sequence to move focus to the first item 
in the menu bar? 
Putting the menu bar only in the tab order eliminates some of the issues 
of where to put focus when a menu is closed.  If the user can only tab to 
the menu, then when all menus are closed focus will return to the first 
menu bar item.  Assigning a keystroke sequence to set focus to the menu is 
helpful for navigation purposes but determining an available sequence that 
does not conflict with the browser or screen reader is difficult. Also, if 
 a special sequence is used, where should focus go when a menu is closed? 
I would guess that focus should go to the item that had focus when the key 
sequence was invoked. If there was no item with focus when the special key 
sequence was invoked then focus would go to the first item in the menu bar 
when a menu was closed.  Also,  catching a sequence to invoke the menu 
implies that there is a onkeydown/press handler at the document level. 
This implies a user interface infrastructure rather than just a stand 
alone widget.

thoughts?


Menu Bar Behavior

Terminology:
Menu bar item is a top level item in a menu bar (Like File, Edit, View in 
Windows Explorer)
open menu is the menu which is associated with a particular menu bar item 
and opens up below that menu bar item
menu item is an item in an open menu or submenu
submenu is an additional menu associated with a particular menu item
parent menu item is the menu item which controls the opening of a menu
cycling focus refers to wrapping the focus through a list of menu items. 
If focus is on the last menu item pressing the right or down arrow (for a 
horizonal or vertical alignment of menu items respectively) will move to 
the first item.  Likewise, when positioned at the first menu item moving 
left or up arrow will move focus to the last menu item. 

Keyboard Behavior

First item in menu bar should be in the tab order (tabindex=0). 
When a menu bar item as focus and no menu is open, pressing left or right 
arrow will cycle focus to the other menu bar items. 
When a menu bar item has focus, pressing enter should open the menu and 
place focus on the first menu item in the opened menu
When a menu bar item has focus, pressing the up or down arrow should open 
the menu and place focus on the first menu item in the opened menu.
With focus on an menu item in an open menu, pressing up or down arrow 
should cycle focus through the items in that menu.
When focus is on a menu item that has a submenu, pressing enter should 
open the submenu.
Pressing escape with focus on an open menu item should close the open menu 
or submenu and return focus to the parent menu item 
With focus on an menu item, pressing enter should invoke that menu action. 
Items in the main menu bar must open menus, not perform actions. 
When a menu item has focus and that item has a submenu, pressing right 
arrow should open the submenu for that item and place focus on the first 
item in the opened submenu
With focus on an open menu item that does not contain a submenu - pressing 
left or right arrow should open the submenu for the previous or next menu 
bar item and place focus on first menu item in the opened submenu (like in 
Windows Explorer menu bar - with focus on Status Bar in View sub menu 
pressing right arrow opens Favorites menu and puts focus on add to 
favorites).
With focus on an open menu item that has a submenu, pressing left arrow 
should open the submenu for the previous  menu bar item and place focus on 
first menu item in the opened submenu. This rule applies recursively no 
matter how many submenus are open at the time of the keypress -- 
everything that is open gets closed, and the next sibling in the main menu 
bar gets opened.
With focus on a sub menu item, up or down arrows should cycle through the 
submenu items (behaves the same as open menu)
With focus on a sub menu item, pressing left arrow will close the submenu 
and return focus to the parent menu item
Disabled menu items receive focus but have no action when enter is 
pressed.
Tabbing out of the menu component will close any open menus. 
With focus on a menu item and a sub menu opened via mouse behavior, 
pressing down arrow will move focus to the first item in the sub menu.
With focus on a menu item and a sub menu opened via mouse behavior, 
pressing up arrow will move focus to the last item in the sub menu.


Mouse Behavior

Mouse over on a menu bar item changes the background of the menu bar item 
but does not focus the menu bar item. 
Clicking on a menu bar item opens the menu and sets focus to the menu bar 
item. Items in the main menu bar can only be opened with a mouse click or 
keyboard action, never a mouse hover. 
Clicking on a menu bar item with an open menu will close the menu and 
remove focus from the menu bar item (focus goes back to the document). 
Note that this has been implemented inconsistently in Windows.
With focus on a menu bar item with an open menu,  mouse over an adjacent 
menu bar item will set focus to that menu bar item and open its menu
Mouse over an menu item sets focus to that item
Mouse over a menu item which has a submenu will open the submenu. Focus 
remains on the parent menu item.
When a menu item which has focus and has a submenu open loses focus 
(because the mouse was moved over an adjacent menu item) the submenu 
closes.
With focus on a menu item via mouse over and no sub menu open for that 
item, moving the mouse out of the open menu returns focus to the parent 
menu item and leaves the menu open
With focus on a menu item via mouse over which has opened a sub menu, 
moving the mouse out of the open menu leaves focus on the parent menu and 
the submenu open
With focus on a submenu item, moving focus out of the submenu returns 
focus to the parent menu item but the submenu remains open.
Clicking out of the menu component  will close any open menus
Clicking on a menu item should invoke that menu action. Items in the main 
menu bar must open menus, not perform actions. 
There should be an adjustable delay between the time you mouseover a 
menu-item-with-submenu and the submenu opens.  On Windows it defaults to 
400ms

Mouse and Keyboard Interaction

The user should be able to switch between using the mouse or the keyboard 
and vice versa at any time. 
If you open a menu (A) with the mouse, hover over a menu-item-with-submenu 
(B) to open its submenu (C), select a menu item (D) in submenu C with the 
keyboard, then click B again, D becomes unselected.  In fact, all submenus 
under C close.  It's as if you moved off B altogether and then immediately 
came back and re-opened it.


Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com

Received on Friday, 9 February 2007 21:31:23 UTC