Keyboard, Focus, and Navigation Restructuring

Kim and I have been reviewing the keyboard and focus related materials in UAAG20, which expanded somewhat as we tried to get a handle on navigation in general.

High-Level Organization

Here's a high-level view of where we feel the success criteria would be best organized:

• Principle 1 Perceivable
  • Guideline 1.3 Provide highlighting for selection, active keyboard focus, enabled elements, visited links
• Principle 2 Operable
  • Guideline 2.1: Ensure full keyboard access
  • Guideline 2.2: Provide sequential navigation
  • Guideline 2.3: Provide direct navigation and activation
  • Guideline 2.4: Provide text search [another form of navigation]
  • Guideline 2.5: Provide structured navigation
  • Guideline 2.6: Provide access to event handlers [using the keyboard]
• Principle 3 Understandable
  • Guideline 3.4 Predictable [don't move keyboard focus without user permission, and avoid side effects]
• Principle 4 Facilitate programmatic access
  • Guideline 4.1 Assistive technology [includes exposing keyboard focus]
  • Guideline 4.2 Nested user agents

Detailed table of contents

Here's a more detailed breakdown, showing all the keyboard and navigation SC plus some of those renumbered as a result of our changes:

• Principle 1 Perceivable
  • Guideline 1.3 Provide highlighting for selection, active keyboard focus, enabled elements, visited links [title changed]
    • 1.3.1 Highlighted Items [changed]
• Principle 2 Operable
  • Guideline 2.1: Ensure full keyboard access [moved 2.1.8 to 2.2, added 2.1.x (former 1.9.1) Keyboard Focus, and 2.1.y Keyboard Navigability (former 1.9.2 and 1.9.4)]
    • 2.1.1 Keyboard Operation [no changes]
    • 2.1.2 Keyboard Focus [former 1.9.1, significant changes]
    • 2.1.3 Keyboard Navigability [former 1.9.2 and 1.9.4, significant changes]
    • 2.1.4 Specify Preferred Keystrokes [former 2.1.2 and 2.1.12, minor changes]
    • 2.1.5 No Keyboard Trap [former 2.1.3, name change]
    • 2.1.6 Separate Selection From Activation [former 2.1.4, no change]
    • 2.1.7 Follow Text Keyboard Conventions [former 2.1.5, name change]
    • 2.1.8 Make Important Command Functions Efficient [former 2.1.9, name change and minor changes]
    • 2.1.9 Override UI Keyboard Commands [former 2.1.10]
  • Guideline 2.2: Provide sequential navigation [includes former 2.1.8 and 1.9.8, and a new SC]
    • 2.2.1 Sequential Navigation Between Elements [This replaces 1.9.8 Bi-Directional AND 2.1.8 Keyboard Navigation]
    • 2.2.2 Sequential Navigation Between Viewports [new]
    • 2.2.3 Default Navigation Order [former 1.9.9]
    • 2.2.4 Options for Wrapping in Navigation [new]
  • Guideline 2.3: Provide direct navigation and activation [includes former 2.1.6, 2.1.7, 2.1.11]
    • 2.3.1 Direct Navigation to Important Elements [former 2.7.4, before that 4.7.2, name change] (Level A)
    • 2.3.2 Direct Activation [former 2.7.6, before that 4.7.5] (Level AA)
    • 2.3.3 Present Direct Commands in Rendered Content [former 2.1.6, before that 4.1.6, also 2.7.1] (Level A)
    • 2.3.4 Present Direct Commands in User Interface [former 2.1.7, before that 4.1.7, also 2.7.1] (Level AA)
    • 2.3.3 User Override of Accesskeys [former 2.1.11, before that 4.1.11]
  • Guideline 2.4: Provide text search [formerly 2.6, no changes]
  • Guideline 2.5: Provide structured navigation [formerly 2.7, no changes]
  • Guideline 2.6: Provide access to event handlers [formerly 2.2, no changes]
  • Guideline 2.7: Configure and store preference settings [formerly 2.5, no changes]
  • Guideline 2.8: Provide toolbar configuration [formerly 2.8, no changes]
  • Guideline 2.9: Allow time-independent interaction [formerly 2.3, no changes]
  • Guideline 2.10: Help users avoid flashing that could cause seizures [formerly 2.4, no changes]
  • Guideline 2.11: Provide control of content that may reduce accessibility [formerly 2.9, no changes]
• Principle 3 Understandable
  • Guideline 3.4 Predictable
    • 3.4.1 Avoid Unpredictable Focus [changed, broadened to not moving focus without user's request or permission]
    • 3.4.2 Avoid Side Effects of Navigation [changed]
• Principle 4 Facilitate programmatic access
  • Guideline 4.1 Assistive technology [renamed]
    • 4.1.6 Properties [includes programmatic access to keyboard focus]
  • Guideline 4.2 Nested user agents [new]
    • 4.2.1 (former 1.9.5, before that 3.11.5) Hand-Off Focus [moved, unchanged]
    • 4.2.2 (former 1.9.6, before that 3.11.6) Retrieve Focus [moved, unchanged]
    • 4.2.3 (former 1.9.7, before that 3.11.7) Return Focus [moved, unchanged]

Major changes include:

1. Principle 1 is Perceivable, and the only portion of focus-related stuff that really belongs under Perceivable is about focus CURSORS. All the other requirements are more appropriate under Principle 2, Operable. The former 1.9 "Keyboard Focus" was a hodgepodge of focus and keyboard items, but in our reorganization it becomes only about providing the basic keyboard focus mechanism and cursors for user feedback. All navigation methods are extracted into various separate guidelines under Principle 2 (Ensure that the user interface is operable), which currently has 2.6 (text search), 2.7 (structured navigation), 2.1.1 (general, which mentions direct navigation), 2.1.6 (direct navigation in content), 2.1.7 (direct navigation in UA UI), 2.1.8 (sequential navigation), etc.
2. SC about Present Direct Commands could be under 2.3 "Provide Direct Navigation and Activation" or under 1 Perceivable.
3. The current 2.1.8 (Keyboard Navigation) combines two requirements: (a) you can navigate to each group/frame, and (b) you can sequentially navigate to all enabled elements within a group/frame. Those should be split up into separate SC, the former is not about HOW you navigate but what you navigate BY, and thus falls into the concept of 2.7, Structured Navigation, while the second is about HOW you navigate (sequentially), and thus belongs under the new 2.x Sequential Navigation.
4. In splitting up 1.9, moved SC about nested user agents into a new guideline, 4.2 Nested user agents, and renamed Guideline 4.1 now that it is not the only guideline under its principle.
5. Regarding 2.7 Structured Navigation, we moved those success criteria about direct navigation/activation to the new guideline 2.3, and several of the remaining SC didn't seem to be about keyboard or navigation so were not addressed. Thus:
   1. 2.7.1 Discover navigation and activation keystrokes, is about direct navigation/activation so becomes 2.3.3 and 2.3.4.
   2. 2.7.2 Access Relationships, did not seem to be about keyboard or navigation and so was not addressed in our proposal.
   3. 2.7.3 Location in Hierarchy, did not seem to be about keyboard or navigation and so was not addressed in our proposal. As we were discussing last week, if it's about navigation then it belongs under
   4. 2.7.4 Direct navigation, is about direct navigation/activation so becomes 2.3.1.
   5. 2.7.5 Access to Relationships which Aid Navigation, did not seem to be about keyboard or navigation and so was not addressed in our proposal.
   6. 2.7.6 Direct activation, is about direct navigation/activation so becomes 2.3.2.
   7. 2.7.7 Configure Set of Important Elements (for structural navigation), should have been included in our reorganization at the end of Guideline 2.5 "Provide Structured Navigation". I putting it there now, along with a placeholder for a new SC that would actually require structural navigation, as we were requiring it to be configurable, but not to be provided in the first place.
6. ...

Here is our proposed text. Comments in square brackets call out or explain the changes to the relevant section.

Principle 1 Perceivable

Guideline 1.3 Provide highlighting for selection, keyboard focus, and enabled elements

[Changed the title from "selection, content focus, enabled elements, visited links" to "selection, keyboard focus, and enabled elements". "Content focus" was changed to "keyboard focus" because it's not just in content. We could leave in "visited links", but it may not be necessary to be that exhaustive in the title given that links are a subset of enabled elements.]

1.3.1 (former 3.5.1) Highlighted Items

[In item (b) we changed "content focus" to "active keyboard focus (indicated by focus cursors and text cursors)", added (c) "active window", and renumbered the remainder. We added a second and explained both items in the Related Resources.]]

The user can specify that the following be highlighted so that each class is uniquely distinguished. It is not the intention that all recognized enabled elements be uniquely distinguished, just that they be distinguished from disabled elements. The user has the option to highlight the following classes of information so that each is uniquely distinguished. (Level A):

1. (a) selection
2. (b) active keyboard focus (indicated by focus cursors and/or text cursors)
3. (c) active window
4. (d) active viewport
5. (e) recognized enabled elements
6. (f) presence of alternative content
7. (g) recently visited links

Intent of Success Criterion 1.3.1 (former 3.5.1):

Users need to be able to easily discover what web content they can interact with. Users with low vision need to be able to highlight selection, content focus, enabled elements and links (including recently visited links) in order to successfully discover and interact with the web content.

Note: In addition to these required categories, it is recommended that user agents also allow the user to highlight the active viewport, even when it is a frame or similar within the active window, which makes it much easier for the user to visually locate the active focus.

Note: Platform conventions will dictate whether or not an inactive keyboard focus (keyboard focus in an inactive viewport) is visually indicated by an inactive cursor.

Examples of Success Criterion 1.3.1 (former 3.5.1):

1. A web site uses styles to override visited link color. A low vision user wants to know what links have yet to be explored. The user agent provides a dialog box for setting overrides to author-selected link colors.
2. An author has created a web site with CSS styles that removes the content focus outline. The user agent provides a dialog box for setting overrides to authors CSS focus outline declaration.

Related Resources for Success Criterion 1.3.1 (former 3.5.1):

1. UAAG 1.3.2 (former 3.5.2) Highlighting Options, describes user options to configuring how these categories are highlighted
2. UAAG 2.1.2 (former 1.9.1) Keyboard Focus requires every window have an active or inactive keyboard focus at all times

Principle 2 Operable

Guideline 2.1 Ensure full keyboard access [moved 2.1.8 to 2.2, added 2.1.2 (former 1.9.1) Keyboard Focus, and 2.1.3 Keyboard Navigability (former 1.9.2 and 1.9.4)]

2.1.1 Keyboard Operation [no changes]

2.1.X Keyboard Focus [former 1.9.1, significant changes]

[Formerly read "Keyboard Focus: At least one keyboard focus is provided for each viewport (including frames), where enabled elements are part of the rendered content. (Level A)". Intent has been changed and former example replaced.]

Every viewport has an active or inactive keyboard focus at all times. (Level A)

Intent for 2.1.2 (formerly 1.9.1):

Both the user and some types of assistive technology need to know what will be affected by any keyboard input, so it's important that they be able to tell which window, viewport, and controls have the keyboard focus at any time. This applies whether window and viewport are active (active keyboard focus) or inactive (inactive keyboard focus). Even when a window is inactive, it can be affected by simulated keyboard input sent by assistive technology tools. Active keyboard focus is indicated to the user by focus cursors and text cursors, as required by Guidelines 1.3, and made available to assistive technology, as required by Success Criterion 4.1.6.

Examples for 2.1.2:

1. Alan launches a web browser and navigates to a web page. Initially the keyboard focus is treated as being on the entire document, and that is exposed to assistive technology, but there is no visible cursor. When he presses the tab key, the focus moves to the first link on the web page, and a cursor in the form of a dotted rectangle appears around that link.
2. Ellen launches a web browser and navigates to a web page that has an enabled edit field. The browser places the keyboard focus on the edit field, so she can immediately start entering text, and it's location is shown using a text cursor (usually a vertical line or i-beam). As Ellen types, the text cursor moves to show where the next character will appear. If she activates another window, the browser may hide the cursor in the now inactive window, but its location is still available to assistive technology.
3. Raymond has low vision. As the keyboard focus moves from one control to another, or one window to another, his screen enlarger utility detects the focus change and pans its viewport to keep the focus location visible.

Related Resources for 2.1.2:

1. Guideline 1.3 (Provide highlighting for selection, active keyboard focus, enabled elements, visited links) ensures that the focus location is made visible to users.
2. Success Criterion 4.1.6 (Properties) ensures that the focus location is available to assistive technology.

2.1.3Y Keyboard Navigability [former 1.9.2, before that 3.11.2, and 1.9.4, before that 3.11.4, significant changes]

[Previously "1.9.2 Current Focus: The user can make the keyboard focus of each viewport the active input focus. (Level A)"; we tried to clarify it.]

The user can move the active keyboard focus to any viewport.

Intent for 2.1.3Y:

Each viewport has a keyboard focus (per 2.1.2), but it's also important that the user be able to navigate to that viewport, making its keyboard focus become the active keyboard focus. This navigation can be between viewports within the application, or between windows or applications. This includes the user agent's user interface, extensions to the user interface (e.g. add-on), content, and plug-ins handling content.

Examples of Success Criterion 2.1.3Y:

1. Ruth is working in her web browser, where one document window (viewport) is active (has the active keyboard focus). When she switches to her word processor, the web browser's window and its keyboard focus become inactive, and it hides its cursor. When she switches back to the browser window, it reactivates that viewport, its keyboard focus becomes active again, and its cursor reappears in the same location as when she switched to a different application.
2. A developer creates an extension to a user agent that allows the user to add notes about each web page being visited. A user can press a shortcut key to move focus to the user interface of this extension and interact with the functionality offered by the extension. Similarly, the user presses another key to move focus back to the main viewport for the user agent in the same location as when she moved to the plugin.

Related Resources for Success Criterion 2.1.3Y (superset of 1.9.4, which was former 3.11.4):

1. 2.2.1 ensures that the user can navigate to elements within the viewport.

Issues for 2.1.3:

1. Does this really incorporate everything we wanted to include from 1.9.2, which said the user can make any keyboard focus the active keyboard focus, and thus was really about reactivating a window that has lost the activation?
2. Is this redundant to other SC?

2.1.4 Specify Preferred Keystrokes [former 2.1.2 and 2.1.12, minor changes]

[2.1.2 and 2.1.12 were essentially duplicates, except the former was Level A and the latter was Level AA, so we combined them, tentatively at Level A. Clarified that the exception is allowed, not required, and changed the inline example to be something so basic that we would not expect it to be configurable. Previous it read "The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g., for access to help)."]

The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user interface controls. Exceptions can be made for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). (Level A)

2.1.5 No Keyboard Trap [former 2.1.3, name change]

[Changed the name from "No Keyboard Trap (Minimum)", as there was no other SC with a name similar name from which the "(Minimum)" had to distinguish it.

2.1.6 Separate Selection From Activation [former 2.1.4, no change]

2.1.7 Follow Text Keyboard Conventions [former 2.1.5, name change]

[Formerly called "Standard Text Area Navigation Conventions", but they examples were not limited to navigation. We also rephrased it in the imperative.]

2.1.8 Make Important Command Functions Efficient [former 2.1.9, name change and minor changes]

[Formerly called "Important Command Functions", we rephrased it in the imperative and emphasize the efficiency aspect that distinguishes this from the separate requirement that everything be keyboard accessible. We inserted the word "easily"]

Important command functions (e.g. related to navigation, display, content, information management) are easily available using a single or efficient sequence of keystrokes or key combinations. (Level AA)

new proposal: Make Important Command Functions Efficient: Important command functions (e.g. related to navigation, display, content, information management) are more efficient than sequential keyboard navigation. (Level AA)

2.1.9 Allow Overriding UI Keyboard Commands [former 2.1.10, renamed]

[Formerly called "Override of UI Keyboard Commands".]

Guideline 2.2 Provide sequential navigation [new, includes former 2.1.8 and 1.9.8, and a new SC]

[This is a new guideline created as a container for existing SC related to sequential navigation, and to parallel guidelines for other types of navigation.]

2.2.1 Sequential Navigation Between Recognized Elements [replaces 1.9.8 Bi-Directional and 2.1.8 Keyboard Navigation]

The user can move the keyboard focus backwards and forwards through all recognized enabled elements in the current viewport. (Level A)

[This SC replaces 1.9.8 Bi-Directional and 2.1.8 Keyboard Navigation; 1.9.8 had no IER, while the text below replaces and expands on the IER for the 2.1.8.]

Intent for 2.2.1:

Sequential keyboard navigation is the most fundamental, universal method of keyboard access. While it can be slower and require more input than other methods (such as direct, structural, or search-based navigation) it is a simpler mechanism that requires very little cognitive load or memorization, and is more consistent across contexts. Users need keyboard access to all viewports and all enabled elements so that they can manipulate them, view them with screen magnifiers, or have them described by screen readers. The ability to move both forward and backward through the navigation order greatly reduces the number of keystrokes and allows the user to more easily recover from mistakes in overshooting a destination.

Examples for 2.2.1:

1. Sooj cannot use a pointing device, so she moves the keyboard focus to the next enabled element by pressing the Tab key, and to the previous enabled element by pressing Shift+Tab. Within list boxes and radio button groups she uses the up and down arrow keys to move to the next and previous items.

Related Resources for 2.2.1:

Issues for 2.2.1:

• Did we lose the "ability to navigate between groups of elements" such as radio button groups? {jim- I don't think so, that is controlled by the UA tab function, it automatically jumps from one radio group to another. the only way to navigate within the group is to use arrows.}

2.2.2 Sequential Navigation Between Viewports [new]

The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A)

[This is a new SC.]

Intent for 2.2.2:

It is important for the user to be able to jump directly to the next or previous viewports without having to visit every element in a viewport on the way to the next viewport, because that can add an exorbitant number of navigation commands to operations that should be both easy and efficient.User need keyboard access to all viewports and all enabled elements so that they can manipulate them, view them with screen magnifiers, or have them described by screen readers. The ability to move both forward and backward through the navigation order greatly reduces the number of keystrokes and allows the user to more easily recover from mistakes in overshooting a destination.

Examples for 2.2.2:

1. Sooj cannot use a pointing device, so she moves the keyboard focus to the next pane by pressing F6 or the previous pane by pressing Shift+F6. She moves between tabbed document views by pressing Ctrl+Tab and Shift+Ctrl+Tab.

Related Resources for 2.2.2:

1. See the description of 2.2.1 for background information on the importance of sequential navigation.

2.2.3 Default Navigation Order [former 1.9.9]

If the author has not specified a navigation order, the default is sequential navigation, in document order. (Level A)

[This was formerly 1.9.9 Sequential Navigation, with new IER as those had not yet been written for 1.9.9.]

Intent for 2.2.3:

The reason for this success criteria is that browsers will be consistent on the tab order they provide WHEN the content author didn't explicitly define one.It is important for users to have a mental map of where the focus will land when they press the Tab key or use other sequential navigation commands. If the focus jumps in seemingly random fashion, skipping up and down, it becomes impossible to use this method efficiently. It requires the user to stop, find the focus, reorient, and determine whether and in which direction they should proceed every single time they press a navigation key. This is a particular problem for users with some cognitive limitations or whose disability makes input difficult, tiring, or painful. Content authors are expected to define a logical navigation order in their documents, but if they have not specified one, this success criterion ensures the order will at least be consistent between user agents.

Examples for 2.2.3:

1. Alec is filling out an HTML form. Because the form's author has not specified a navigation order using the tabindex attribute, when Alec presses the Tab key the focus moves to the next control in the order they are defined in the underlying HTML. This order is likely to seem logical as long as the author is not using styles to change the order in which which the controls appear on page, but even if that is not the case, Alec will still experience the same order when using different browsers on different computers, and therefore navigating the page can become an accustomed habit and much easier than if the order were to change from one system to the other.

Related Resources for 2.2.3:

1. See Web Content Accessibility Guidelines 2.0 success criterion 2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

2.2.4 Options for Wrapping in Navigation [new]

The user can have sequential navigation prevent wrapping or can receive feedback when wrapping. (Level AA)

Intent for 2.2.4:

Users need a good mental map of the navigation sequence and behavior, and particularly need to know when they have started over again so they can maintain that mental map and not waste time and energy inadvertently revisiting information. This is a greater problem for users who can only perceive a limited region (e.g. having a narrow field of vision, or using a screen magnifier or screen reader) or have limited short-term memory. This also prevents people with mobility issues from having to use extra navigation commands.

Examples for 2.2.4:

1. Betsy is using a screen magnifier that only shows her a single line of text. She's navigating through a long list of unsorted items in a list box, searching for one particular entry which, it turns out, is not in the list. Each time she presses the down arrow she is presented with the next item in the list. This particular list box wraps, so when she has read the final entry and presses the down arrow, she is once again presented with the first entry in the list. Unfortunately, because she is quickly discounting every entry that is not her intended goal, she hasn't memorized the list, and it takes her a long time to realize that she's scrolling through the same set of items again and again. To avoid having this happen again, she can turn on options to prevent wrapping, or have the user agent play a sound or present a message before or as it wraps back to the first item. However, keyboard users who can see the entire screen may very well benefit from having wrapping without being interrupted by a pop-up dialog box, so ideally this behavior should be under the user's control.

Related Resources for 2.2.4:

Guideline 2.3 Provide direct navigation and activation [includes former 2.1.6, 2.1.7, 2.1.11]

2.3.1 Direct Navigation to Important Elements [former 2.7.4, before that 4.7.2, title changed] (Level A)

<<Greg Lowney 2011-04-20: It seems like for the purposes of structural navigation (e.g. go to next h2) and structural views (e.g. outline view) you'd certainly want the user to be able to define the set of important elements (e.g. only show headings of level 3 or higher). But for direct navigation and activation in content (e.g. Mouseless Browsing) would it be acceptable for it to just include all operable elements?>>

2.3.2 Direct Activation [former 2.7.6, before that 4.7.5, renumbered only] (Level AA)

2.3.3 Present Direct Commands in Rendered Content [former 2.1.6, before that 4.1.6, also 2.7.1, minor change] (Level A)

[The only change to 2.1.6 was taking out the inline examples, which were already in the list of bulleted examples. 2.1.6 and 2.7.1 were highly overlapping: 2.1.6 was "2.1.6 (former 4.1.6) Present Direct Commands in Rendered Content: The user can have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (e.g. "[Ctrl+t]" displayed after a link whose accesskey value is "t", or an audio browser reading the value or label of a form control followed by "accesskey control plus t"). (Level A) ", while 2.7.1 was "2.7.1 (former 4.7.7) Discover navigation and activation keystrokes: Direct navigation and activation keystrokes are discoverable both programmatically and via perceivable labels. (Level A)". The part of 2.7.1 about programmatically belongs under Principle 4 Programmatic Access, not here.]

The user can have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (Level A)

Intent of Success Criterion 2.3.3 (former 2.1.6 and 4.1.6):

Make it easy to for users to discover or be reminded of keyboard shortcuts and similar commands without leaving the context in which they're working. Easy keyboard access is especially important for people who cannot easily use a mouse. An example of this is mouseless browsing. Some users have problems controlling the mouse and/or the keyboard. Therefore users often find control by speech recognition to be advantageous. In this case it is much more efficient for navigation and activation selection points to be both viewable by the user and controllable by their assistive technology.

Examples of Success Criterion 2.3.3 (former 2.1.6 and 4.1.6):

1. "[Ctrl+t]" displayed after a link whose accesskey value is "t".
2. An audio browser reading the value or label of a form control followed by "accesskey control plus t").
3. Mary cannot use the mouse or keyboard due to a repetitive strain injury, instead she uses voice control technology with uses a mouse-less browsing plug-in to her browser. The plug-in overlays each hyperlink with a number that can then be used to directly select it (e.g. by speaking the command "select link 12"). This prevents Mary from having to say the word 'tab' numerous times to get to her desired hyperlink.

Related Resources for Success Criterion 2.3.3 (former 2.1.6 and 4.1.6):

1. See 2.1.7 for User Interface commands
2. Mouseless Browsing Firefox Extension: https://addons.mozilla.org/en-us/firefox/addon/mouseless-browsing/
3. Perceivable navigation and activation keys: http://www.mouseless.de/index.php?/content/view/17/30/
4. Microsoft placing Wikipedia on TV-DVD and using mouseless browsing via remote control: http://research.microsoft.com/research/tem

2.3.4 Present Direct Commands in User Interface [former 2.1.7, before that 4.1.7, also 2.7.1, minor change] (Level AA)

[The only change to 2.1.7 was taking out the inline example, which was already in the list of bulleted examples. 2.1.7 and 2.7.1 were highly overlapping: 2.1.7 was "2.1.7 (former 4.1.7) Present Direct Commands in User Interface: The user has the option to have any direct commands (e.g. keyboard shortcuts) in the user agent user interface be presented with their associated user interface controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar button). (Level AA) ", while 2.7.1 was "2.7.1 (former 4.7.7) Discover navigation and activation keystrokes: Direct navigation and activation keystrokes are discoverable both programmatically and via perceivable labels. (Level A)". The part of 2.7.1 about programmatically belongs under Principle 4 Programmatic Access, not here.]

The user has the option to have any direct commands (e.g. keyboard shortcuts) in the user agent user interface be presented with their associated user interface controls. (Level AA)

2.3.5 Allow Overriding of Accesskeys [former 2.1.11, before that 4.1.11, renamed]

[Renamed from "Override of Accesskeys" to "Allow Overriding of Accesskeys"] {?? but the title is something different again "User Override of Accesskeys" - what should it be??}

Guideline 2.4 Provide text search [formerly 2.6, no changes]

Guideline 2.5 Provide structural navigation [formerly 2.7, renamed]

[Changed name from "structured" to "structural navigation".]

2.5.1 Provide structural navigation [new]

[We required the user agent let the user specify the set of important elements for structured navigation, but did not actually have a success criterion requiring structured navigation itself. We should add one or more.]

2.5.2 Specify Elements for Structural Navigation [formerly 2.7.7, before that 4.7.6, moved and renamed only]

[Changed name from "Configure Set of Important Elements" to something I hope is both more specific and concise, "Specify Elements for Structural Navigation".]

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

[Added "or role" to ensure that ARIA role mappings to non-semantic elements are captured in the navigation --Markku Hakkinen 16:18, 21 April 2011 (UTC)]

Intent for Success Criterion 2.5.3:

[To be written]

Examples for Success Criterion 2.5.3:

• [To be written]

Related Resources for Success Criterion 2.5.3:

• [To be written]

Guideline 2.6 Provide access to event handlers [formerly 2.2, no changes]

Guideline 2.7 Configure and store preference settings [formerly 2.5, no changes]

Guideline 2.8 Provide toolbar configuration [formerly 2.8, no changes]

Guideline 2.9 Allow time-independent interaction [formerly 2.3, no changes]

Guideline 2.10 Help users avoid flashing that could cause seizures [formerly 2.4, no changes]

Guideline 2.11 Provide control of content that may reduce accessibility [formerly 2.9, no changes]

Principle 3 Understandable

Guideline 3.4 Predictable

3.4.1 Avoid Unpredictable Focus [formerly 3.4.2, before that 5.4.2, and 1.9.10, broadened]

[3.4.2 (Unpredictable Focus) overlapped considerably with 1.9.1 (Only On User Request), both of which said the focus should not move without the user's permission or request. However, 3.4.2 had two aspects, notification and prevention. We didn't think notification was practical. We also remove the word "option" per new group convention. We also added the section "Users can…where they want to work." to the Intent paragraph.]

The user can prevent focus changes that are not a result of explicit user request. (Level A)

Intent for 3.4.1: [expanded]

Users need to know that navigation in a web page is going to start in a predictable location and move in a predictable fashion. If a page moves the initial focus to somewhere other than the beginning of the page, the user may not realize they have skipped over some content, especially if they can only see a small portion of the page at a time. Similar problems may occur if the content or user agent automatically moves the focus while the user is reading or entering data on a page. If the focus moves without the user recognizing it, they can easily end up entering data in an incorrect field or taking other unintentional actions. Users can also become confused or disoriented when a window scrolls when they haven't requested it. This is particularly problematic for users who can only see a small portion of the document, and thus have to use more effort to determine their new context. Such users also are more likely to continue typing, not immediately realizing that the context has changed. Users for whom navigation is time consuming, tiring, or painful (including those using screen readers or with impaired dexterity) may also need more steps to return to the area where they want to work. While we recognize it may improve accessibility for some users on some pages to have the page to set focus to specific link or field when the page loads, it can also be detrimental for some users, and therefore users needs to be in control of this behavior.

Examples of Success Criterion 3.4.1 (former 5.4.1): [no change]

1. Jerome has loaded a page that sets its default focus to a search box. Because he wants to read the content of the page, rather than starting by entering data, it takes him additional scrolling to get to the content that was not in the search box. To prevent this, he adjusts his browser's settings to disable the automatic focus change on this page.
2. Jessica uses a screen enlarger, and loads a page that contains instructions followed by a form. If the page automatically moves the keyboard focus to the form, she may not realize there were instructions. To avoid this problem, she sets an option to prevent default focus changes.
3. James uses speech recognition. He speaks his credit card number by saying several digits and, if needed, Tab keys, in a single phrase. He needs to know ahead of time whether it is necessary to include the Tab command in the phrase.
4. Joey is filling in a Web form that asks for his phone number using three separate fields. When she types the three digits of her area code into the first field, the browser automatically moves the focus to the second field. This can be a problem for two reasons, first because if Joey is not looking at the screen she does not realize that the focus has moved for her, and so she presses the Tab key to move it manually, not realizing that this now puts the focus on the third field rather than the the second. It can also pose a problem if Joey realizes that she typed one digit incorrectly in the area code field, because when she presses Shift+Tab to return and edit that field, the browser or content script checks the number of digits that have been entered, and seeing that it is three, automatically moves the focus once again, preventing her from editing the number. To avoid these problems, Joey goes to her browser's Preferences dialog box and checks the option that prevents focus changes that she has not explicitly requested.
5. Justine uses a keyboard macro to execute a multistep command at a specific location. The focus changes without her control, so the command fails or executes with unpredictable results.

Related Resources for Success Criterion 3.4.1 (former 5.4.1): [no change]

1. UAAG 2.0 3.10.8 Don't Move Focus

Issues for 3.4.1:

• This SC had not been assigned a Level; we have proposed Level A.

{jim- agree with Level A}

3.4.2 Avoid Side Effects of Navigation [former 1.9.1, before that 3.11.11, changed]

The user can move the keyboard focus without causing the user agent to take any further action, other than the presentation of information (e.g. scrolling or pop-ups that do not change the focus or selection). (Level A)

Intent of 3.4.2:

People do not expect side effects when moving the keyboard focus. If users fail to notice side effects, they could end up doing something disastrous, and this is especially likely for users of assistive technology who cannot see changes happening elsewhere on the screen. Users may also find it confusing or disorienting if the effect causes unexpected focus movement or changes in context. If the user agent does implement side effects to keyboard navigation, it is recommended that it provide a user preference setting to disable them. However, in some cases it may be more appropriate to provide a separate navigation mechanism that avoids side effects, such as allowing the user to hold down the Ctrl key while navigating to avoid changing selection or choice.

Note: It may not be possible for the user agent to detect or prevent side effects implemented by scripts in the content, but the user agent is required to prevent side effects that are under its control.

Examples of Success Criterion 3.4.2:

• Murray uses a screen enlarger that allows him to see the element with the focus and a small area around it. He explores a dialog box by repeatedly pressing the Tab key to move to, and read, each control in succession, although he has to use the arrow keys to navigate between options in an option group. On this platform moving the focus to an option control automatically chooses that option, making it cumbersome for him because of the need to reset the choice to its original state afterward. Fortunately, the platform also has a convention that holding down the Ctrl key while navigating will move the focus without changing selection or option choice, so Murray uses this while exploring. His Web browser implements its own form controls and navigation mechanisms rather than using the platform's infrastructure, but it also implements this Ctrl-key mechanism for users like Murray.

Related Resources for Success Criterion 3.4.2:

Issues for 3.4.2:

• This SC had not been assigned a Level; we have proposed Level A.

Principle 4 Assistive technology [renamed only]

Guideline 4.1 Facilitate programmatic access

4.1.6 Properties [includes programmatic access to keyboard focus, unchanged]

[This heading is included only because it is related to keyboard, but it is not changed.]

Guideline 4.2 Nested user agents

[This new guideline was created as a placeholder for the SC (formerly 1.9.5, 6 and 7) that are describe how nested user agents are handled. These do not belong in Guideline 4.1 because that is about cooperation with accessibility aids, rather than between user agents, and they certainly did not really fit under any of the other four principles.]

4.2.1 (former 1.9.5, before that 3.11.5) Hand-Off Focus [moved, unchanged]

The user agent programmatically notifies any nested user agent(s) (e.g., plug-ins) when active input focus moves to a nested agent. (Level A)

Intent of Success Criterion 4.2.1 (former 1.9.5, before that 3.11.5):

To be written

Examples of Success Criterion 4.2.1 (former 1.9.5, before that 3.11.5):

• A browser plug-in is installed to play a popular media format. When the user tabs to the controls for the plug-in, the user agent notifies the plug-in to handle keyboard interaction.

Related Resources for Success Criterion 4.2.1 (former 1.9.5, before that 3.11.5):

• To be written

4.2.2 (former 1.9.6, before that 3.11.6) Retrieve Focus [moved, unchanged]

At any time, the user agent is able to retrieve input focus from a nested viewport (including nested viewports that are user agents). (Level A) {jim-'at any time' implies that I am in the middle of some nested viewport and with a push of a key can jump out of that viewport back to my home viewport. is that what you meant?}

Intent of Success Criterion 4.2.2 (former 1.9.6, before that 3.11.6):

To be written

Examples of Success Criterion 4.2.2 (former 1.9.6, before that 3.11.6):

• To be written

Related Resources for Success Criterion 4.2.2 (former 1.9.6, before that 3.11.6):

• To be written

4.2.3 (former 1.9.7, before that 3.11.7) Return Focus [moved, unchanged]

An embedded user agent is responsible for notifying the embedding user agent that active input focus should move back to it. (Level A)

Intent of Success Criterion 4.2.3 (former 1.9.7, before that 3.11.7):

• To be written

Examples of Success Criterion 4.2.3 (former 1.9.7, before that 3.11.7):

• To be written

Related Resources for Success Criterion 4.2.3 (former 1.9.7, before that 3.11.7):

• To be written