- Important note: This Wiki page is edited by participants of the User Agent Accessibility Guidelines working group (UAWG). It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

Guideline 2.7

From WAI UA Wiki
Revision as of 18:47, 7 April 2011 by Jeanne (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Guideline 2.7

Guideline 2.7 Provide structured navigation.

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 word '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/
Microsoft placing Wikipedia on TV-DVD and using mouseless browsing via remote control: http://research.microsoft.com/research/tem

Proposed 2.7.2 Access Relationships

Move to 1.11.2. See wiki text. Guideline 1.11

Proposed 2.7.3 Location in Hierarchy

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

Proposed 2.7.4 Direct navigation

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

Proposed 2.7.5 Access to Relationships which Aid Navigation

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.

Proposed 2.7.6 Direct activation

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

Proposed 2.7.7 Configure Set of Important Elements

2.7.7 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