Problem Reporting
Chapter 2 Input Models
3.3 Menu Traversal
The Menu traversal model is different from the field traversal model. This allows Menus to be traversable even when the focus policy is implicit. If a
*
Menu is traversed to while the focus policy in the application is implicit, the
*
focus policy must temporarily change to explicit. The focus policy must
*
revert to implicit whenever the user traverses out of the Menu system.
Traversing to a Menu system is the same as activating the Menu system. If
*
the MenuBar is inactive, <FlO> must traverse to, or activate, the MenuBar
*
system. The location cursor must be placed on the first traversable
*
CascadeButton in the MenuBar. If there are no traversable CascadeButtons
*
in the MenuBar, <FlO> must do nothing. Note that <Shift> <Menu> is used on systems where <FlO> is not available.
If the keyboard focus is on an element with an inactive Popup Menu and the
*
<Shift> <FlO> is used on systems where <Menu> is not available.
If the keyboard focus is in an OptionButton, <Select> or <Space> must post
*
the Option Menu. The location cursor must be placed on the previously
*
selected item in the Option Menu. If the Option Menu is pulled down for
*
the first time, the location cursor must be placed on the default item in the
*
Menu. If there are no traversable items in the Option Menu, the application should decide whether to post the Menu or not. If there is an active Option
*
Menu, <Enter>, <Return>, <Select>, or <Space> must select the current
*
item in the Option Menu, unpost the active Option Menu system, and return
*
the location cursor to the OptionButton.
Once a Menu system is posted, the Menu items can be traversed using <J..>,
<f->, <~>, and <I>. A posted Menu system behaves somewhat like a field, with the addition of traversing among Menus in the system. When a
*
Menu traversal action traverses to the next or previous component in a
*
Menu or MenuBar, the order of traversal and the wrapping behavior must be
*
Navigation
the same as that of the corresponding component navigation action within a
*
field, as described in Section 3.2.3.
Two-dimensional Menus must not contain CascadeButtons.
*
The following Menu traversal behavior must be supported:
*
<-1-> This action must do the following:
*
<f->
• If the component is in a vertical or 2-dimensional Menu,
*
traverse down to the next traversable component,
*
wrapping within the Menu if necessary.
*
• If the component is in a MenuBar, and the component
*
with the keyboard focus is a CascadeButton, post its
*
associated Pulldown Menu and traverse to the default
*
entry in the Menu or, if the Menu has no default, to the
*
first traversable entry in the Menu.
*
If the component is in a vertical or 2-dimensional Menu, this
*
action must traverse up to the previous traversable
*
component, wrapping within the Menu if necessary, and
*
proceeding in the order opposite to that of <1.>.
This action must do the following:
*
• If the component is in a MenuBar or 2-dimensional Menu,
*
but not at the left edge, traverse left to the previous
*
traversable component.
*
• If the component is at the left edge of a MenuBar, wrap
*
within the MenuBar.
*
• If the component is at the left edge of a vertical or 2-
*
dimensional Menu that is the child of a vertical or 2-
*
dimensional Menu, unpost the current Menu and traverse
*
to the parent CascadeButton.
*
• If the component is at the left edge of a vertical or 2-
*
dimensional Menu that is the child of a MenuBar, unpost
*
the current Menu and traverse left to the previous
*
traversable entry in the MenuBar. If that entry is a
*
CascadeButton, post its associated Pulldown Menu and
*
traverse to the default entry in the Menu or, if the Menu
*
has no default, to the first traversable entry in the Menu.
*
<~> This action must do the following:
*
• If the component is a CascadeButton in a vertical Menu,
*
post its associated Pulldown Menu and traverse to the
*
default entry in the Menu or, if the Menu has no default,
*
to the first traversable entry in the Menu.
*
• If the component is in a MenuBar or 2-dimensional Menu,
*
but not at the right edge, traverse right to the next
*
traversable component.
*
• If the component is at the right edge of a MenuBar, wrap
*
within the MenuBar.
*
• If the component is not a CascadeB utton and is at the
*
right edge of a vertical or 2-dimensional Menu, and if the
*
current Menu has an ancestor CascadeButton (typically in
*
a MenuBar) from which <J.-> posts its associated
*
Pulldown Menu, unpost the Menu system pulled down
*
from the nearest such ancestor CascadeButton and
*
traverse right from that CascadeButton to the next
*
traversable component. If that component is a
*
CascadeButton, post its associated Pulldown Menu and
*
traverse to the default entry in the Menu or, if the Menu
*
has no default, to the first traversable entry in the Menu.
*
For all Menu traversal actions, when the Menu is first posted, traversal should go to the second traversable entry in the Menu if the Menu has no default and the first traversable entry is a TearOffButton. Subsequent
*
traversal actions must traverse to the TearOffButton in the same way as for
*
other Menu entries.
The user can use keyboard actions to exit a Menu or a Menu system in the following way:
• When a MenuBar system is active, <FlO> should unpost the entire Menu system.
• When a Popup Menu system is active, <Menu> should unpost the entire
Menu system.
*
• In a Pulldown Menu, <Cancel> must either dismiss the Menu and move
*
the location cursor to the CascadeButton used to pull down the Menu, or
*
unpost the entire Menu system.
*
Navigation
• In a Popup Menu, Option Menu, TearOff Menu, or MenuBar, <Cancel>
*
must unpost the Menu system.
*
• When <FlO>, <Menu>, or <Cancel> is used to unpost an entire Menu
*
system and an explicit focus policy is in use, the location cursor must be
*
moved back to the component that had it before the Menu system was
*
posted.