- From: David Poehlman <poehlman1@comcast.net>
- Date: Sat, 10 Feb 2007 09:24:45 -0500
- To: Becky Gibson <Becky_Gibson@notesdev.ibm.com>
- Cc: wai-xtech@w3.org
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