Guidelines to Gateway to Techniques

End to End analysis of Guideline 2.1

Analysis of the table below:

The gateway repeats the text of Guideline except it paraphrases it using different words. Is it necessary to repeat the Guideline in the Technology Independent Document? And if so should it not use the exact wording of the Guideline? (the gateway may be using an old wording from the guideline) As per our discussion on Wed Jun 9, a tab index is perhaps not recommended as is suggested in Gateway 2.1. There is quite a bit of repetition between the Guideline informative and the Gateway Informative. the Gateway could perhaps provide an explanation of a "more abstract" event handler or maybe that should happen in the glossary of the guidelines. CSS is a styling issue so keyboard access is not really an issue.

	Guideline	Technology Independent Doc	HTML Techniques	CSS

Guideline 2.1	2.1: Make all functionality operable via a keyboard or a keyboard interface.			N/A
Success Criteria 1:	Level 1 : All of the functionality of the content, where the functionality or its outcome can be described in a sentence, is operable through a keyboard or keyboard interface.	2.1 Ensure that all functionality is operable at a minimum through a keyboard or a keyboard interface. 2.1.2 Tabbing order Provide a logical tab order through the content. Task 4.2 Manually test pages with various user agents and settings used by people with disabilities. 4.2#4 Use other tools such as a self-voicing browser (e.g., [PWWEBSPEAK] and [HOMEPAGEREADER]), a screen reader (e.g., [JAWS] and [WINVISION]), magnification software, a small display, an onscreen keyboard, an alternative keyboard, etc. Note. If a Web site is usable with one of these products it does not ensure that the site will be usable by other products. For a more detailed list of assistive technologies used to access the Web refer to ([ALTBROWSER]).	Keyboard access Use Client Side Image Map Provide text links for server side image maps. Provide redundant text links for client side image map. Keyboard shortcuts for directly accessible scripts.	N/A
Success Criteria 2:	Level 2 : Wherever a choice between input device event handlers is available and supported, the more abstract event is used.	none	Device independent event handlers	N/A
Success Criteria 3:	Level 3 : All of the functionality of the content is operable via a keyboard or keyboard interface.		Provide redundant text links for client side image map. (is this Out?)	N/A
Informative	Who Benefits from Guideline 2.1 (Informative) Individuals who are blind (and cannot use pointing devices) can have access to the functionality of the Web content or site. Individuals with severe physical disabilities can use speech input (which simulates keystrokes) to both enter data and operate the interface elements on the page. Examples of Guideline 2.1 (Informative) Example 1: operation with multiple input devices. The content relies only on focus-in, focus-out, and activation events; these are defined in the API of the environment for which the content is written, and are intended to be operable by a variety of input devices, including pointing devices, keyboards and speech input systems. Example 2: examples of Web content that would and would not be operable from a keyboard or keyboard interface If it's written to be operable from a computer keyboard, it conforms. (because it is operable from the keyboard.) If it's written to be used on a device that doesn't usually have a keyboard such as a cell phone, but it can be controlled by an optional keyboard for that device, it conforms. (A person who needs a keyboard - or alternate keyboard - can use it to control the application.) If it's written to be used with a device that doesn't have a keyboard, but it could also be used by similar devices that do and it would work with their keyboard, it conforms. (A person who needs a keyboard would not buy the device without the keyboard. That device may itself not be considered accessible. But the content can be controlled from a device with a keyboard and therefore conforms to this guideline.) If it's written to work with devices that do not have keyboards and it can not be used by any other devices that do have keyboards, then it does not conform. (It cannot be accessed via keyboard.)	Not every user has a graphic environment with a mouse or other pointing device. Some users rely on keyboard, alternative keyboard or voice input to navigate links, activate form controls, etc. Content developers must ensure that users may interact with a page with devices other than a pointing device. A page designed for keyboard access (in addition to mouse access) will generally be accessible to users with other input devices. What's more, designing a page for keyboard access will usually improve its overall design as well. Keyboard access to links and form controls may be specified in a few ways: Provide keyboard shortcuts so that users may combine keystrokes to navigate links or form controls on a page. Note. Keyboard shortcuts -- notably the key used to activate the shortcut -- may be handled differently by different operating systems. On Windows machines, the "alt" and "ctrl" key are most commonly used while on a Macintosh, it is the apple or "clover leaf" key. Refer to the Keyboard access for links and Keyboard Access to Forms sections for examples. Editorial Note: Update references to WCAG10. Should we even be including pointers to technology specific items in our gateway discussion?

Guideline

Technology Independent
Doc

HTML Techniques

CSS

Guideline 2.1

2.1: Make all functionality operable via a keyboard or a keyboard interface.

N/A

Success Criteria 1:

Level 1 : All of the functionality of the content, where the functionality or its outcome can be described in a sentence, is operable through a keyboard or keyboard interface.

2.1 Ensure that all functionality is operable at a minimum through a keyboard or a keyboard interface.

2.1.2 Tabbing order
Provide a logical tab order through the content.

Task 4.2 Manually test pages with various user agents and settings used by people with disabilities.

4.2#4 Use other tools such as a self-voicing browser (e.g., [PWWEBSPEAK] and [HOMEPAGEREADER]), a screen reader (e.g., [JAWS] and [WINVISION]), magnification software, a small display, an onscreen keyboard, an alternative keyboard, etc. Note. If a Web site is usable with one of these products it does not ensure that the site will be usable by other products. For a more detailed list of assistive technologies used to access the Web refer to ([ALTBROWSER]).

N/A

Success Criteria 2:

Level 2 : Wherever a choice between input device event handlers is available and supported, the more abstract event is used.

none

Device independent event handlers

N/A

Success Criteria 3:

Level 3 : All of the functionality of the content is operable via a keyboard or keyboard interface.

Provide redundant text links for client side image map. (is this Out?)

N/A

Informative

Who Benefits from Guideline 2.1 (Informative)

Individuals who are blind (and cannot use pointing devices) can have access to the functionality of the Web content or site.
Individuals with severe physical disabilities can use speech input (which simulates keystrokes) to both enter data and operate the interface elements on the page.

Examples of Guideline 2.1 (Informative)

Example 1: operation with multiple input devices.
The content relies only on focus-in, focus-out, and activation events; these are defined in the API of the environment for which the content is written, and are intended to be operable by a variety of input devices, including pointing devices, keyboards and speech input systems.
Example 2: examples of Web content that would and would not be operable from a keyboard or keyboard interface
- If it's written to be operable from a computer keyboard, it conforms. (because it is operable from the keyboard.)
- If it's written to be used on a device that doesn't usually have a keyboard such as a cell phone, but it can be controlled by an optional keyboard for that device, it conforms. (A person who needs a keyboard - or alternate keyboard - can use it to control the application.)
- If it's written to be used with a device that doesn't have a keyboard, but it could also be used by similar devices that do and it would work with their keyboard, it conforms. (A person who needs a keyboard would not buy the device without the keyboard. That device may itself not be considered accessible. But the content can be controlled from a device with a keyboard and therefore conforms to this guideline.)
- If it's written to work with devices that do not have keyboards and it can not be used by any other devices that do have keyboards, then it does not conform. (It cannot be accessed via keyboard.)

Not every user has a graphic environment with a mouse or other pointing device. Some users rely on keyboard, alternative keyboard or voice input to navigate links, activate form controls, etc. Content developers must ensure that users may interact with a page with devices other than a pointing device. A page designed for keyboard access (in addition to mouse access) will generally be accessible to users with other input devices. What's more, designing a page for keyboard access will usually improve its overall design as well.

Keyboard access to links and form controls may be specified in a few ways: Provide keyboard shortcuts so that users may combine keystrokes to navigate links or form controls on a page. Note. Keyboard shortcuts -- notably the key used to activate the shortcut -- may be handled differently by different operating systems. On Windows machines, the "alt" and "ctrl" key are most commonly used while on a Macintosh, it is the apple or "clover leaf" key. Refer to the Keyboard access for links and Keyboard Access to Forms sections for examples.

Editorial Note: Update references to WCAG10. Should we even be including pointers to technology specific items in our gateway discussion?