W3C home > Mailing lists > Public > wai-xtech@w3.org > February 2007

More menu discussions

From: Becky Gibson <Becky_Gibson@notesdev.ibm.com>
Date: Mon, 26 Feb 2007 14:38:42 -0500
To: wai-xtech@w3.org
Message-ID: <OFDA5602E7.FA3B9FC1-ON8525728E.00553C63-8525728E.006BEAF4@LocalDomain>

In early February I proposed menu behavior and asked a few questions and 
got some feedback [1].  I am still struggling with menu implementation so 
here is are some additional questions.  Menus are used a bit differently 
on the Web as they generally provide navigation rather than action on some 
object.   There are sites which nest these navigation type menus. Consider 
www.fidelity.com - this Site has what appear to be two nested horizontal 
menu bars.  On the Fidelity site in the tab order after "contact us" is a 
set of links:  Accounts & Trade, Research, Retirement & Guidance, 
Investment Products, Your Profile, Customer Service.  These are visually 
styles somewhat like tab panels but when you focus on one of these links 
the main content of the page does not update. Instead, an additional 
horizontal list of item appears below.  When I focus or click on Accounts 
& Trade, a list appears below it with links labeled, Portfolio, Account 
Positions, Trade, Transfer Money/Shares, Billpay, Update 
Accounts/Features, Statements, Full View.  Likewise, each of the other top 
level items also have an associated menu.  I can't find a way to get focus 
from Accounts & Trade or the other top level menus (except for the last) 
into the menu associated with it.  I am struggling as to how to best 
present this to the user. 

I believe these are nested horizontal menus. But, there is no way to 
distinguish between a horizontal and vertical menu - there is no 
accessibility api that makes that distinction.   Generally menubars are 
assumed to be horizontal and menus are assumed to be vertical.   Thus, 
when you are navigating a menu bar, the left and right arrow keys are used 
and up or down arrow opens any associated submenu.  In a menu, the up and 
down arrow keys traverse the menu items and the right or left arrow key 
opens any associated submenu. 

The problem is that most operating system menubars have a fairly 
complicated use pattern that I documented in my previous email.  The 
behavior that I am referring to is that once a submenu has been opened in 
a menubar there is no way to close it.  When there are open submenus, 
pressing the left or right arrow key may eventually lead to the submenu of 
the next menubar item being opened.   This seems like overkill for the way 
menus are used on the Web and I would like to explore alternative 
behavior.  While I think it is important to maintain a parity of behaviors 
on the Web and the Operating Systems for ease of use, I'd like feedback on 
the following proposal. 

Basically I would like menubar and menu to work the same except one is 
horizontal and the other is vertical and the key usage follows the 
orientation.   This description is similar to the one proposed previously 
with some of the menu bar behavior removed. It also allows nesting of 
menubars. 

-First item in menu bar should be in the tab order (tabindex=0). 
-When a menu bar item has 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 or child menu bar
-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 or 
child menubar.
-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 and put focus on the first submenu item.
-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 
(which may be to open a submenu). 
-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 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 or 
left/right arrow 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.
-With focus on a submenu item, the user must use arrows or the escape key 
to progressively close submenus and move up to the parent item(s).

Mouse Behavior

-Mouse over on a menu bar item focuses the menu bar item (this is 
different from the previous proposal).
-Clicking on a menu bar item opens the menu but leaves focus on the menu 
bar item. 
-Clicking on a menu bar item with an open menu will close the menu and set 
focus to the menu bar item 
-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
-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. Timing for opening the submenu needs to 
be determined. To be more consistent with keyboard operation we should 
consider requiring the user to click on the menu item to open the submenu 
but this differs from current Windows menu behavior.
-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.  Should consider that when mouse moves 
out of the open menu, the menu closes and focus goes back to the parent. 
-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. Should consider that men mouse moves out of the open 
menu, the menu and submenus close and focus goes back to the parent.
-With focus on a submenu item, moving the mouse out of the submenu returns 
focus to the parent menu item but the submenu remains open. Should 
consider that moving the mouse out of the submenu closes the submenu and 
returns focus to the parent.
-Clicking out of the menu component  will close any open menus 
-Clicking on a menu item should invoke that menu action or open the 
submenu. 
-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.  Consider removing the automatic open of menus on mouse over and 
require the user to click to open submenus - this is more consistent with 
keyboard action but differs from Windows menu behavior. 

I realize that this is a large volume of information to process but I am 
struggling to make accessible menus on the web and may need to make some 
compromises.   Is it reasonable to abandon some of the Windows operating 
system conventions for how a menubar behaves and make menubars be a 
horizontal implementation of a menu? 

thoughts appreciated.
-becky


[1] http://lists.w3.org/Archives/Public/wai-xtech/2007Feb/0008.html

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 Monday, 26 February 2007 19:38:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:42 GMT