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 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 | 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)
Examples of Guideline 2.1 (Informative)
|
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?
|