From the 2.7.1 email from Simon with edits from Jan's Comments on 2.7:

Proposed 2.7.1 Discover navigation and activation keystrokes:

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

Intent:

This is sometimes known as mouse-less 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:

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 work 'tab' numerous times to get to her desired hyperlink.

Related Resources:

Mouseless Browsing Firefox Extension:
https://addons.mozilla.org/en-us/firefox/addon/mouseless-browsing/
Perceivable navigation and activation keys:
http://www.mouseless.de/index.php?/content/view/17/30/

Summary

Details

From the 2.7.2 email from Simon:

Proposed

2.7.2 (former 4.7.3) Access Relationships: The user can access explicitly-defined relationships based on the user's position in content (e.g., show form control's label, show label's form control, show a cell's table headers). (Level A)

Intent

HTML controls and elements are sometimes grouped together to make up a composite control; certain elements explicitly relate to others. This is the case with Ajax widgets and with form elements. By making sure the user can access these explicit relationships means that, say, visually disabled users can better understand these relationships even if the elements are not adjacent on the screen or the DOM.

Examples

John has low vision and uses a screen magnifier to access his Browser. When interacting with tables and spreadsheets John has to move the viewport of the magnifier to understand the row and column titles of the cell with which he is interacting. This takes additional time and effort and is therefore frustrating. John has just purchased a new Browser because it presents the row and column titles when he hovers over a cell - this makes him much more productive at his accounting job.

Related Resources:

WAI-ARIA
UAAG 2.7.3 Location in Hierarchy

Summary

Details

From the 2.7.2 email from Simon:

Proposed

2.7.3 (former 4.7.4) Location in Hierarchy: The user can view the path of nodes leading from the root of any content hierarchy in which the structure and semantics are implied by presentation, as opposed to an explicit logical structure with defined semantics (such as the HTML5 Canvas Element), or as a consequence of decentralized-extensibility (such as the HTML5 item / itemprop microdata elements), and only if the user agent keeps an internal model of the hierarchy that it does not expose via the DOM or some other accessibility mechanism. (Level A) .

Intent

Knowing where you are in a hierarchy makes it easier to understand and navigate information. Users who are perceiving the data linearly (such as audio speech synthesis) do not receive visual cues of the hierarchical information. Efficient navigation of hierarchical information reduces keystrokes for people for whom a key-press is time-consuming, tiring, or painful. For people with some cognitive disabilities, providing the clear hierarchy reduces cognitive effort and provides organization. For instance, a media player provides a hierarchical display of playlists, albums, artists and songs, etc. When the user selects an individual item, a breadcrumb of the categories is displayed, can be navigated and is available programmatically.

Examples

Jane works for a leading PR company and has been blind from birth. Her job requires her to do a significant amount of Web surfing in gossip and human interest magazine sites. However, in the charge towards HTML5 many of these sites are replacing standard html content with slick 'Canvas' designs. While the hierarchical information is present (otherwise her browser would not be able to render it) this is not available to Jane. This means that her assistive technology has no way of gaining access to the information. Jane needs a browser which, where present, makes the canvas hierarchy explicit and available to both herself and her assistive technology; just like it does for the page DOM.

Related Resources:

HTML5
WAI-ARIA
UAAG 2.7.2 Access Relationships

Summary

Details

From the 2.7.4 Attempt #2 email from Simon:

Simon's note: I'm wondering if this should move to 2.7.1 and everything else move down one?

Proposed

2.7.4 (former 4.7.2) Direct navigation: The user can navigate directly to important (structural and operable) elements in rendered content. (Level A).

Intent

It is often difficult for some people to use a pointing device (the standard method of direct navigation) to move the viewport and focus to important elements. In this case some other form of direct navigation - such as numbers or key combinations assigned to important elements - should be available which can then be accessed via the keyboard or speech control technology.

Examples

See example for 2.7.1: Discover navigation and activation keystrokes

Related Resources:

2.7.7 configure set of important elements

Summary

Details

From the 2.7.2 email from Simon:

Proposed

2.7.5 (former 4.7.1) Access to Relationships which Aid Navigation: The user can access explicitly-defined relationships based on the user's position in content, and the path of nodes leading from the root of any content hierarchy to that position. (Level AA).

Intent

Let the user use the keyboard to navigate forwards and backwards through elements that they are likely to be interested in interacting with. These elements must include, but are not limited to, enabled links and controls. This allows the user to jump between elements without having to navigate through intervening content such as blocks of text. Efficient keyboard navigation is especially important for people who cannot easily use a mouse. Efficient keyboard navigation aids structured navigation by enhancing a users comprehension of their position (e.g., show form control's label, show label's form control, show a cell's table headers, etc.).

Examples

Jane has mobility problems and cannot use the mouse to make direct link selections. She uses the keyboard for all her interaction with the system and instead of selecting links with the pointing device she uses the browsers built in sequential navigation system by pressing the Tab key to move the focus to the next link or control in the page, and press Shift+Tab to move in the reverse order.

Related Resources:

See 2.1.4 for a discussion of letting the user configure the list of important elements to suit their task.

Summary

Details

From the 2.7.6 email from Simon:

Simon's note: Maybe this should move to 2.7.2 and everything else move down one.

Proposed

2.7.6 (former 4.7.5) Direct activation: The user can move directly to and activate any operable elements in rendered content. (Level AA)

Intent

It is often difficult for some people to use a pointing device (the standard method of direct navigation) to select links. In this case some other form of direct selection - such as numbers or key combinations assigned to important elements - should be available which can then be accessed via the keyboard or speech control technology.

Examples

See example for 2.7.1: Discover navigation and activation keystrokes

Related Resources:

2.7.7 configure set of important elements

Summary

Details

From the 2.7.7 email from Simon:

Proposed

2.7.7 (former 4.7.6) 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)

Intent

All users are not the same, all devices are not the same. What may be important for the efficient interaction of some users are not important for others. In this case, user agents should start with a general set of elements that may be important such as headers, list items, images, and like but enable the addition or removal of elements from this list as the user wishes.

Examples

John is on a low income and cannot afford both a general computer and a television. In this case, John accesses the Web via his digital television and uses a remote control to do this. By allowing John to customise the elements which are important to him, the embedded browser developers have helped John have a more fulfilling browsing experiences and speeded up his interaction with the web content he finds useful.

Related Resources:

N/A

Summary

Details