• NavMechanisms

Guideline 9. Provide navigation mechanisms

9.1 Provide content focus (P1)

1. Provide at least one content focus for each viewport (including frames) where enabled elements are part of the rendered content.
2. Allow the user to make the content focus of each viewport the current focus.

Normative inclusions and exclusions

1. When a viewport includes no enabled elements (either because the format does not provide for this, or a given piece of content has no enabled elements), the content focus requirements of the following checkpoints do not apply: 1.2, 5.1, 5.4, 6.6, 7.1, 9.3, 9.4, 9.5, 9.6, 9.7, 10.2, and 11.5.

Notes

• For example, when two frames of a frameset contain enabled elements, allow the user to make the content focus of either frame the current focus. Note that viewports "owned" by plug-ins that are part of a conformance claim are also covered by this checkpoint. See checkpoint 7.1 for information about implementing content focus according to operating environment conventions.

UAAG2 ISSUES

• need to update the definitons of "enable elements" and "interactive elements" to provide for components used in DHTML/AJAX. Definition change may impact the scope of other checkpoints.
• Where is the line drawn between what the UA vs Author coding should do to provide for accessibility.

Proposals

• Definition of "interactive element" needs to no longer say that the interactive elements are defined by specification alone since any element can be made interactive with JS.
  • "An interactive element is piece of content that, by specification or by programmatic enablement, may have associated behaviors to be executed or carried out as a result of user or programmatic interaction." etc.
• UA should provide focus to chrome elements, all standard HTML form widgets, all elements set to receive focus according to author markup, and any HTML elements made interactive by their rendering (e.g. scrollable divs, scrollable iframes).

9.2 Provide user interface focus (P1)

1. Provide a user interface focus.

Normative inclusions and exclusions

Notes

• See checkpoint 7.1 for information about implementing user interface focus according to operating environment conventions.

UAAG2 ISSUES

• are extensions to the user interface (chrome) considered part of the 'base' UA? Should extensions conform to UAAG? We think, yes. Does UAAG need addtional checkpoints to cover this? Will adding techniqes to cover this, change the scope of the checkpoint?
• Definition of Content. Related to Compound Documents and DHTML/AJAX. Focus management between base UA and nested/child UA (Object, flash, mathml, svg). Also, applications within web content that create a new user interface. Is this new application with it's own user interface considered a new embedded UA that must conform to UAAG or just more content?

Proposals

• User agent is responsible for providing user interface focus to chrome extensions. (If it knows how to insert and render the extension in its chrome, then it should have good enough programmatic access and knowledge to properly give focus.)
• User agent is responsible for notifying any nested user agent that focus should move into it (but the outer UA can't control whether or not the inner one respects focus).
  • Outermost UA (browser?) should provide a way to skip over misbehaving embedded UAs that "eat" focus.

9.3 Move content focus (P1)

1. Allow the user to move the content focus to any enabled element in the viewport.
2. Allow configuration so that the content focus of a viewport only changes on explicit user request.
3. If the author has not specified a navigation order, allow at least forward sequential navigation, in document order, to each element in the set established by provision one of this checkpoint.

Sufficient techniques

1. To satisfy provision two of this checkpoint, configuration is preferred, but is not required if the content focus only ever changes on explicit user request.

Normative inclusions and exclusions

1. The user agent may also include disabled elements in the navigation order.

Notes

• In addition to forward sequential navigation, the user agent should also allow reverse sequential navigation. See checkpoint 9.9 for information about structured navigation. See checkpoints 5.1 and 6.6 for more information about focus changes.

UAAG2 ISSUES

• consider combining 9.3 (move content focus forward) with 9.7 (move content focus reverse). Add 'moving backward' to requirement 1 of 9.3. Moving content focus forward and backward is standard functionality in UAs.

Proposal

• To combine with backward, remove note and make first requirement explicit:
  • Allow the user to move the content focus forward or backward to any enabled element in the viewport.

9.4 Restore viewport state history (P1)

1. For user agents that implement a viewport history mechanism, for each state in a viewport's browsing history, maintain information about the point of regard, content focus, and selection.
2. When the user returns to any state in the viewport history (e.g., via the "back button"), restore the saved values for the point of regard, content focus, and selection.

Normative inclusions and exclusions

1. The viewport history associates values for these three state variables (point of regard, content focus, and selection) with a particular document object. If the user returns to a state in the history and the user agent retrieves new content, the user agent is not required to restore the saved values of the three state variables.
2. Conformance profile labels: Selection

UAAG2 ISSUES

• browser has base functionality to save the 3 states- but content and user configuration can change this. Need to add to Note:. This may change scope of the check point.

Proposals

• Add Note saying "Both user agent settings and scripts in content may affect the ability of the UA to restore state history. The UA is not responsible for overcoming these factors."

9.5 No events on focus change (P2)

1. Allow configuration so that moving the content focus to or from an enabled element does not automatically activate any explicitly associated event handlers of any event type.

Normative inclusions and exclusions

1. Conformance profile labels: Events

Notes

• For instance, in this configuration for an HTML document, do not activate any handlers for the onfocus, onblur, or onchange attributes. In this configuration, user agents should still apply any stylistic changes (e.g., highlighting) that may occur when there is a change in content focus.

UAAG2 ISSUES

• the UA does not know know the state of event handlers.
• events on DHTML controls, related to WAI_ARIA

Proposals

• When is not activating event handlers beneficial? Is this checkpoint even desired now that many Web pages included JS-driven interactive content?

9.6 Show event handlers (P2)

1. For the element with content focus, make available the list of input device event types for which there are event handlers explicitly associated with the element.

Normative inclusions and exclusions

1. Conformance profile labels: Events

Notes

• For example, allow the user to query the element with content focus for the list of input device event types, or add them directly to the sequential navigation order described in checkpoint 9.3. See checkpoint 1.2 for information about activation of event handlers associated with the element with focus.

UAAG2 ISSUES

9.7 Move content focus in reverse (P2)

1. Extend the functionality required in provision three of checkpoint 9.3 by allowing the same sequential navigation in reverse document order.
2. As part of satisfying provision one of this checkpoint, the user agent must not include disabled elements in the navigation order.

Normative inclusions and exclusions

UAAG2 ISSUES

Proposals

• Combine with 9.3. See proposals in that section.

9.8 Provide text search (P2)

1. Allow the user to search within rendered text content for a sequence of characters from the document character set.
2. Allow the user to start a forward search (in document order) from any selected or focused location in content.
3. When there is a match, do both of the following:
   • move the viewport so that the matched text content is at least partially within it, and
   • allow the user to search for the next instance of the text from the location of the match.
4. Alert the user when there is no match or after the last match in content (i.e., prior to starting the search over from the beginning of content).
5. Provide a case-insensitive search option for text in scripts (i.e., writing systems) where case is significant.

Normative inclusions and exclusions

Conformance detail: For all rendered content

Notes

• If the user has not indicated a start position for the search, the search should start from the beginning of content. Per checkpoint 7.3, use operating environment conventions for indicating the result of a search.

UAAG2 ISSUES

• allow searching within conditional content. Also, what happens when condtional content - "alt" (images on) become rendered content - "alt" (images off)
• Remove requirement 2 of 9.8.. removing requirement for "forward" search implies that requiement 1 includes the current functionality of UAs providing forward/backward search functionality [3]

Proposals

• Whether conditional content is rendered or not, it should be searched if it's intended for human consumption, exists in the markup of the page, and is not hidden via a style attribute.
• Yes, remove 9.8 requirement 2.

9.9 Allow structured navigation (P2)

1. Allow the user to navigate efficiently to and among important structural elements in rendered content.
2. As part of satisfying provision one of this checkpoint, allow forward and backward sequential navigation.

Normative inclusions and exclusions

Notes

• This specification intentionally does not identify which "important elements" must be navigable as this will vary by specification. What constitutes "efficient navigation" may depend on a number of factors as well, including the "shape" of content (e.g., sequential navigation of long lists is not efficient) and desired granularity (e.g., among tables, then among the cells of a given table). Refer to the Techniques document [UAAG10-TECHS] for information about identifying and navigating important elements.

UAAG2 ISSUES

• Change "allow" to "provide", structured navigation should be provided natively, not added on by AT.
• Issue/Technique: add technique or requirement stating that UA must provide object attributes (element name and roles, etc.) to the accessibiltiy API to enable structured navigation function by AT

this is an issue if we change wording to "provide" this is a technique if wording remais as "allow"

Proposals

• If "provide":
  • "Provide efficient navigation over important structural elements in rendered content."
• Why is exposing role/state information to accessibility API an issue if providing but only a technique if allowing? Information needs to be exposed regardless so the AT can report role/state information whether the UA is doing the structured nav or the AT is driving it. But it is more important if the AT is in charge.

9.10 Configure important elements (P3)

1. Allow configuration of the set of important elements and attributes identified for checkpoints 9.9 and 10.4.
2. As part of satisfying provision one of this checkpoint, allow the user to include and exclude element types in the set.

Normative inclusions and exclusions

Notes

• For example, allow the user to navigate only paragraphs, or only headings and paragraphs, or to suppress and restore navigation bars, or to navigate within and among tables and table cells.

UAAG2 ISSUES

• consider removing and adding as a "doing more "technique for 9.9 and 10.4, or adding configuration as a requirement for 9.9 and 10.4.

Proposals

• Depends on group consensus.