Re: Menu Behavior and Implementation

Hi Becky,  IHere are my thoughts from what I understand of your  
message inline below your questions where I have any.  I think this  
warrants close study by the group and others though because we want  
to be certain we don't break any future implementation possibilities.

On Feb 9, 2007, at 4:31 PM, Becky Gibson wrote:


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.
dp: +1 but this might be something to be configurable by the AT.

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.
dp: as to tab order vs not/hotkey envocation, we might want to assign  
thiss to the possibilities for listings of items.  we have for  
instance, lists of headers, lists of links, lists of lists, tables  
and so on, why not a list of menus unless there is always one only of  
course?  I'd actually want to see something like this done both ways  
in order to effectively respond, but would lean toward a direct  
navigation implementation since if we re taalking about something  
like the ie7 menus, I dfind them cumbersom to tab through.
thoughts?
I hope this helps and spurrrs discussion.

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 Saturday, 10 February 2007 14:25:01 UTC