Re: Focus indicators for grouped controls

As much as I like bright-line criteria, a definition of focus should be
based on user experience, not on platform-specific features like
document.activeElement. Otherwise we'll neglect a variety of *input
modalities* and *UI patterns*.

Focus tells users:

   - Where am I in [sequential navigation]? and
   - What am I interacting with?

Users fill in the blank "[sequential navigation]" with their *input
modality*.

   - Keyboard or AT: tab order
   - Speech input: "tab"
   - Kiosk keypad: next/previous
   - Game controller or similar: arrow pad
   - Other sequential navigation commands depending on context, such as
   keyboard: arrow keys
   - Other keyboard-like mechanisms not yet invented

Mouse and touch are not in this list because they aren't sequential
navigation. I'm not sure about caret navigation.

Many *UI patterns* require sequential navigation that's not as simple as
"next" and "previous". (WC)AG will need to acknowledge UI patterns like
these both inside and outside of the browser.

   - Two sequence axes, one focus location:
      - Menu bar with menus and menu items
      - Tree
      - Grid
   - Multiple dependent focus locations:
   - Combo box with option list
      - Windows and panels
      - Rich editor and toolbar
   - Multiple independent focus locations:
   - Single user: Up/down and left/right modify independent input controls
      - Multi-user: Two game controllers on one game
   - Combinations:
   - A combo box with a multi-select grid pop-up
      - A rich editor with embedded editable interactive objects

When things get complex, it might be useful to think of focus as subclass
of selection.

Mitchell Evan
+1 (510) 375-6104
mtchllvn@gmail.com
https://www.linkedin.com/in/mitchellrevan/