Menu Bar, Menu Button, Menu, and Menu Items

[charlie-yao]

• Menu
• Menubar
• Menu Button
• Menuitem
• Parent Menuitem
• Menuitem Checkbox
• Menuitem Radio
• Separator

https://www.w3.org/TR/wai-aria-practices-1.1/#menu
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-2/menubar-2.html

https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-links.html
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions.html
https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-actions-active-descendant.html

https://www.w3.org/TR/wai-aria-1.1/#menu
https://www.w3.org/TR/wai-aria-1.1/#menubar
https://www.w3.org/TR/wai-aria-1.1/#menuitem
https://www.w3.org/TR/wai-aria-1.1/#menuitemcheckbox
https://www.w3.org/TR/wai-aria-1.1/#menuitemradio
https://www.w3.org/TR/wai-aria-1.1/#separator

TODO:

• differentiate between "base-level" aria components and opinionated stuff? (e.g. pure functional components that help us know what aria/html attributes to add by using proptypes vs logic/state layer vs CSS/cosmetics layer)
  • demo (e.g. styled, stateful, etc.) vs opinionated (handles refs and events and methods) vs base (functional components that are totally unopinionated)
  • opinionated layer accepts components as props that provide styling? demos provide these components? possibly better than specifying classname/styles/component when defining the items array - no need to repeat the same thing for every item, avoid possible confusion as to where a classname should be applied if it's a more complex component like ParentMenuItem, etc.
  • provide styling for any (?) expanded menu/sub-menu
• finish implementing state/focus management
  • account for menu orientation
  • how to handle state changes and item activation (isDisabled, isChecked, etc.)?
  • how to handle index-based focusing when accounting for "separator" (part of items array but not focusable) and "radiogroup" (part of items array but has children)?
  • disable onActivate if, well, disabled
  • better abstractions for state and focus management
    • rework navigation/focus API?
      • combine focusmenubaritem props?
      • how should parentmenuitem know if it's a child of a menubar or a menubutton? (account for root navigation?)
      • how necessary is flattenedPosition? do we need distinct radiogroups? what are the actual semantics of grouping? (e.g. is it possible for radio options to refer to a group via some aria attribute rather than being children of a role="group"?) flattenedPosition may be necessary to an extent - possibly don't need the full position, just the index, flattened index, and root flattened index
    • consolidate rendering code?
    • consolidate events?
      • since events can bubble, possibly split up responsibilities between items and parent menus? or use another abstraction?
    • consolidate focus/navigation code?
      • possible to consolidate methods like focus() or focusFirstChild()? offload methods to a HOC?
  • mouse behavior
    • Menu mouse hover interactions would require contradictions to the APG w3c/aria-practices#598
    • Menubar examples: Make mouse behaviors and parent menu item appearance change triggers more consistent with desktop conventions w3c/aria-practices#408
    • Menubar examples: Make mouse behaviors and parent menu item appearanc… w3c/aria-practices#593
    • open and collapse
      • Review editor menubar example (menubar-2.html) w3c/aria-practices#144 (comment)
      • opening menus on click
      • only automatically open menus/submenus if a menu is already opened
      • when to collapse menus?
        • probably not on mouse exit for application menubars, only when clicking outside the menu?
        • if a menu is already opened and you hover over another one?
        • upon activating an item?
    • focus follows mouse movements? e.g. if you hover over a menu item and then do the up arrow, go up relative to where the mouse was rather than the most recent focus-modifying keyboard movement?
    • make a distinction between navigation menubars and application menubars, and only implement application menubar behavior?
• components
  • menu button
  • menubar
  • menu
  • menuitem
  • parent menuitem
  • menuitemcheckbox
  • menuitemradio
  • menuitemradiogroup
  • separator
• demo menubar
• demo menubar with different orientations
• demo menubutton
• demo menubutton with different orientations
• organize comments, proptypes, etc. be mindful of labeling requirements and document them.

Before Merging:

• double-check authoring practices - https://www.w3.org/TR/wai-aria-practices-1.1/#menu
• double-check adherence to WCAG
• double-check code (obviously! :P)

Won't Do (for now):

• activate upon something like shift + F10
• focus on items when entering a printable character
• worry about sorting/filtering/etc. menu items
• navigation-focused behavior
  • nav menu item - there's debate over whether navigation fits here
  • automatically open on hover (even then this behavior is debatable - provide a flag to toggle?)
  • parent menuitems that act as a navigation anchor in itself - clicking them navigates to a destination rather than simply expanding the submenu
  • Menubar examples: Draft note about mouse hover behavior w3c/aria-practices#603
• rendering optimization