ACTION-210 - Proposed 4.7

In response to our assigned action for the past week, Kim, Henny, and I put
forward the following as revised and extended Guideline 4.7:

Guideline 4.7 Provide structured and direct navigation

4.7.1 Structured Navigation: Forward and backward sequential navigation over
important (structural and operable) elements in rendered content is
provided. (Level A)

4.7.2 Direct navigation: direct movement to important (structural and
operable) elements in rendered content is provided. (Level A).

4.7.3 Direct activation: direct movement to and activation of any operable
elements in rendered content is provided. (Level AA)

4.7.4 Configure Set of Important Elements: The user has the option to
configure the set of important elements for structured navigation, including
by element type (e.g., headers, list items, images). (Level AAA) @@Editor's
note: Review the definition of "important elements" @@

4.7.5 Direct navigation and activation keystrokes are discoverable both
programmatically and via perceivable labels. (Level A)

Background rationale/discussion:

Provide a mechanism to allow direct or sequential navigation to elements
within content.  These elements may be structurally/semantically significant
elements that would make navigation or reading of content more efficient for
users of assistive technology. These elements may also be actionable
elements, such as hyperlinks, form controls, or user interface widgets
within a rich internet application.

Speech and keyboard users clearly benefit from a "shortcut" key model, as
proposed by Kim, the idea being that the UA or AT will auto-label and assign
a unique numeric key sequence to an operable element. Screen reader users
clearly benefit from being able to filter and review the structure, via
lists, or direct/sequential navigation via "structure nav keys".  This is
really the same problem, with different presentation/interaction approaches
based on the user requirement (non-visual vs. visual presentation).

A screen magnification and speech user may benefit from hybrid UI combining
structural keyboard nav and numeric-based keyboard selection of what is
brought into view.  For example, one might envision customization that would
simplify and adapt the the numbering in that case so as to only number what
is currently in view.  Different approaches to implementing and displaying
the numbering/shortcut scheme would be described in the techniques
document.

User configurability of shortcut keys/display is a key requirement.

Some discussion items... resolution may again be most appropriate for
techniques:

There is some concern about the mixing/over-ride of app-supplied key
commands with auto-generated key labels. Pass-through display of author
defined keys? Configurable?

How might the overall semantic structure of the page influence the numbering
scheme, or should it just be tab order?

Numbering appears effective for many users, but what about a mnemonic value
vs the autogenerated numeric sequence?   Is it possible to auto generate any
meaningful mnemonic key selectors?

Can an experienced user who regularly visits a site expect to have familiar
and un-changing numeric selectors?

If numbering sequences were initialized from a fixed starting value, for
each WAI ARIA landmark region, would that make life easier, more
predictable?


mark