Web Content Accessibility Guidelines 2.0 -- View 5 - Best Practice and Additional Notes Only

W3C Working Draft 23 Sept. 2003

This version:
Latest version:
Ben Caldwell, Trace R&D Center
Wendy Chisholm, W3C
Gregg Vanderheiden, Trace R&D Center
Jason White, University of Melbourne


This draft is the fourth in a series of reorganization proposals.


W3C published the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) as a Recommendation in May 1999. This Working Draft for version 2.0 builds on WCAG 1.0. It has the same aim: to explain how to make Web content accessible to people with disabilities and to define target levels of accessibility. Incorporating feedback on WCAG 1.0, this Working Draft of version 2.0 focuses on checkpoints. It attempts to apply checkpoints to a wider range of technologies and to use wording that may be understood by a more varied audience.

Status of this Document

This document is an editors' copy that has no official standing.

This document is prepared by the Web Content Accessibility Guidelines Working Group (WCAG WG) to show how more generalized (less HTML-specific) WCAG checkpoints might read. This draft is not yet based on consensus of the WCAG Working Group nor has it gone through W3C process. This Working Draft in no way supersedes WCAG 1.0.

Please refer to "Issue Tracking for WCAG 2.0 Working Draft" for a list of open issues related to this Working Draft. The "History of Changes to WCAG 2.0 Working Drafts" is also available.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents is available.

The Working Group welcomes comments on this document at public-comments-wcag20@w3.org. The archives for this list are publicly available. Archives of the WCAG WG mailing list discussions are also publicly available.

Patent disclosures relevant to this specification may be found on the WCAG Working Group's patent disclosure page in conformance with W3C policy.

This document has been produced as part of the W3C Web Accessibility Initiative (WAI). The goals of the WCAG WG are discussed in the Working Group charter. The WCAG WG is part of the WAI Technical Activity.

Table of Contents

Guideline 1: PERCEIVABLE. Make Content Perceivable by Any User

Core Checkpoints for Guideline 1

1.1 [CORE] All non-text content that can be expressed in words has a text equivalent of the function or information that the non-text content was intended to convey.

Best Practice Measures for Checkpoint 1.1
  1. non-text content that can not be expressed in words has a text equivalent for all aspects that can be expressed in words.

  2. a text document that merges all audio descriptions and captions into a collated script (that provides dialog, important sounds and important visual information in a single text document) is provided.

1.2 [CORE] Synchronized media equivalents are provided for time-dependent presentations.

Editorial Note (06/10/03): There is discussion about moving some of the current success criteria from Required to Best Practice or to an Extended checkpoint. The issue stems from trying to apply the success criteria to every Web cam, newscast, and home broadcast. Another approach is to allow a conformance claim to state, for example, "All pages and applications on this site meet the Core checkpoints of WCAG 2.0 except the Web cam at http://example.org/webcam/."

Best Practice Measures for Checkpoint 1.2
  1. Editorial Note: This whole Checkpoint (1.2) needs reworking. Perhaps move some down from above, or limit the items above to just certain classes of content - and then put the rest of the coverage (for other types of content) here.

  2. captions and audio descriptions are provided for all live broadcasts.

  3. the presentation does not require the user to read captions and the visual presentation simultaneously in order to understand the content.

1.3 [CORE] Information, functionality, and structure are separable from presentation.

Best Practice Measures for Checkpoint 1.3
  1. any information presented using color is also available without color and without having to interpret markup.[I#317]

  2. any blinking content can be turned off.[I#325]

1.4 [CORE] All text can be decoded into words represented in Unicode.

Best Practice Measures for Checkpoint 1.4
  1. abbreviations and acronyms are clearly identified each time they occur if they collide with a word in the standard language that would also logically appear in the same case (e.g. all caps). (See also checkpoint 3.1) [I#341]

  2. symbols such as diacritic marks that are found in standard usage of the natural language of the content, and that are necessary for unambiguous identification of words, are present or another standard mechanism for disambiguation is provided.

Extended Checkpoints for Guideline 1

1.5 [E1] Structure has been made perceivable through presentation. [I#439]

Best Practice Measures for Checkpoint 1.5
  1. the structural emphases are chosen to be distinct on different major visual display types (e.g. black and white, small display, mono audio playback).

  2. Content is constructed such that users can control the presentation of structural elements or the emphasis on the structure can be varied through alternate presentation formats.

Additional Notes for Checkpoint 1.5 (Informative)
  1. for visual presentations, font variations, styles, size and white space can be used to emphasize structure.

  2. color and graphics can be used to emphasize structure.

  3. for auditory presentations, different voice characteristics and/sounds can be used for major headings, sections and other structural elements.

  4. if content is targeted for a specific user group and the presentation of the structured content is not salient enough to meet the needs of your audience, additional graphics, colors, sounds, and other aspects of presentation can be used to emphasize the structure.

1.6 [E2] Foreground content is easily differentiable from background for visual default presentations.

Best Practice Measures for Checkpoint 1.6
  1. when text content is presented over a background image or pattern, the text is easily readable when the page is viewed in 256 grayscale.

    Editorial Note: this item may be moved or updated if the proposal for adding an extended checkpoint on color is accepted.

  2. this item should read identically to the required item #2, except that it should say "in default presentation mode."

Editorial Note: The working group is seeking an algorithm that measures contrast in a way that is accurate and testable enough that we could include it in the guidelines. One algorithm, which comes from the Techniques For Accessibility Evaluation And Repair Tools document, is currently under consideration for inclusion in the techniques, but the group has not yet found something that is specific enough to be included at the guidelines level.

1.7 [E3] Foreground content is easily differentiable from background for auditory default presentations.

1.8 [E4] [color vision is not required to perceive content (or something like this to allow color-coding issues to exist at extended checkpoint level)]

Best Practice Measures for Checkpoint 1.8
  1. content can be perceived with no color vision

Guideline 2: OPERABLE. Ensure that Interface Elements in the Content are Operable by Any User

Core Checkpoints for Guideline 2

2.1 [CORE] All functionality is operable at a minimum through a keyboard or a keyboard interface.

Best Practice Measures for Checkpoint 2.1
  1. wherever a choice between event handlers is available and supported, the more abstract event is used.

2.2 [CORE] Users can control any time limits on their reading, interaction, or responses unless control is not possible due to nature of real-time events or competition.

Best Practice Measures for Checkpoint 2.2
  1. any moving content can be frozen using the keyboard[I#325]

2.3 [CORE] User can avoid experiencing screen flicker.

Editorial Note (06/10/03): This Checkpoint is currently included in the Core set of Checkpoints because the WCAG WG expects that it will be possible to test content for flicker and the result will be a flicker rate in Hz that can be stored in a machine-readable format. If the assumption regarding a testing tool does not hold at time of final review of these guidelines, this checkpoint will be moved to the Extended set of Checkpoints."

Best Practice Measures for Checkpoint 2.3
  1. animation or other content does not visibly or purposely flicker between 3 and 49 Hz.

  2. content that might create a problem has been tested [using XYZ tool]; only pages with unavoidable flicker remain and appropriate warnings along with a close alternative presentation have been provided for these pages.

Extended Checkpoints for Guideline 2

2.4 [E5] Mechanisms have been added to facilitate orientation and movement in content.

Best Practice Measures for Checkpoint 2.4
  1. the content has been reviewed, taking into account the following strategies for facilitating orientation and movement, applying them as appropriate.

    1. breaking up text into logical paragraphs

    2. providing hierarchical sections and titles, particularly for longer documents

    3. revealing important non-hierarchical relationships, such as cross-references, or the correspondence between header and data cells in a table, so that they are represented unambiguously in the markup or data model

    4. dividing very large works into sections and or chapters with logical labels

    5. others?

  2. information is provided that would allow an assistive technology to determine at least one logical, linear reading order.

  3. diagrams are constructed in a fashion so that they have structure that can be accessed by the user.

  4. where possible, logical tab order has been created.[I#319]

2.5 [E6] Methods are provided to minimize error and provide graceful recovery.

Best Practice Measures for Checkpoint 2.5
  1. where possible, the user is allowed to select from a list of options as well as to generate input text directly

  2. errors are identified specifically and suggestions for correction are provided where possible

  3. checks for misspelled words are applied and correct spellings are suggested when text entry is required.

  4. where consequences are significant and time-response is not important, one of the following is true

    1. actions are reversible

    2. where not reversible, actions are checked for errors in advance

    3. where not reversible, and not checkable, a confirmation is asked before acceptance

Guideline 3: UNDERSTANDABLE. Make content and controls understandable to as many users as possible.

Core Checkpoints for Guideline 3

3.1 [CORE] Language of content can be programmatically determined.

Best Practice Measures for Checkpoint 3.1

Extended Checkpoints for Guideline 3

3.2 [E7] The definition of abbreviations and acronyms can be unambiguously determined.

Editorial Note: The CKW reorganization suggested that this checkpoint be combined with checkpoint 1.4. [I#442]

Best Practice Measures for Checkpoint 3.2
  1. a list is provided on the page or home page of URIs to cascading dictionaries that can or should be used to define abbreviations or acronyms.[I#350]

  2. the content has been reviewed, taking into account the following strategies for determining the definition of abbreviations and acronyms, applying them as appropriate.

    1. provide a definition or link (with the first occurrence) of phrases, words, acronyms, and abbreviations specific to a particular community.

    2. provide a summary for relationships that may not be obvious from analyzing the structure of a table but that may be apparent in a visual rendering of the table.

    3. if contracted forms of words are used such that they are ambiguous, provide semantic markup to make words unique and interpretable.

3.3 [E8] Content is no more complex than is necessary and/or is supplemented with simpler forms of the content.  

Best Practice Measures for Checkpoint 3.3
  1. the content has been reviewed, taking into account the strategies for evaluating the complexity of the content, applying them as appropriate.

Additional Notes for Checkpoint 3.3 (Informative)

Strategies for evaluating the complexity of the content include:

  1. use of sentence structures that increase understanding

    • such as active voice in languages where this form helps convey information

  2. length of noun phrases

    • strings of no more than three or four nouns are easiest to understand

  3. clarity of reference with pronouns and anaphoric expressions (these refer back to something already said in the text)

    • example of potential ambiguity: "Scientists study monkeys. They eat bananas."

  4. correct use of conjunction forms and adverbs to make explicit the relationship between phrases or parts of the text

    • such as "and," "but," "furthermore," "not only"

  5. complexity of verb tenses

    • do the tenses used in a document seem overly complicated?

  6. intelligibility of verb phrases

  7. familiarity of idioms or slang

  8. logic in the order and flow of information

  9. consequences of ambiguity or abstraction

  10. improved readability of vertical lists might offer in place of long paragraphs of information

  11. use of summaries to aid understanding

  12. thoroughness in the explanation of instructions or required actions

  13. consistency in the use of names and labels

  14. clarity where the document:

    • addresses users

    • explains choices and options

    • labels options to get more information

    • instructs users how to modify selections in critical functions (such as how to delete an item from a shopping cart)

  15. application of:

    • proper markup to highlight key information

    • goal-action structure for menu prompts

    • default settings (and the ease in re-establishing them)

    • two-step "select and confirm" processes to reduce accidental selections for critical functions

    • calculation assistance to reduce the need to calculate

  16. testing with potential users for ease of accessibility

  17. use of a controlled language

  18. providing support for conversion into symbolic languages

  19. adding non-text content to the site for key pages or sections specifically to make the site more understandable by users who cannot understand the text only version of the site.

3.4 [E9] Layout and behavior of content is consistent or predictable, but not identical.  

Best Practice Measures for Checkpoint 3.4
  1. user can select a different location for navigation elements in the layout of the page.[I#352]

  2. the content has been reviewed, taking into account common ideas for making content consistent and predictable, applying them as appropriate.

Additional Notes for Checkpoint 3.4 (Informative)
  1. common ideas for making content consistent and predictable indclude:

    1. place navigation bars in a consistent location whenever possible

    2. similar layout for user interface components should be used for sections or whole site

    3. similar user interface components should be labeled with similar terminology

    4. use headers consistently

    5. use templates for consistent presentation of sections or whole site

    6. pages with similar function should have similar appearance and layout

    7. controls that look or sound the same should be designed to act the same

    8. conventions likely to be familiar to the user should be followed

    9. unusual user interface features or behaviors that are likely to confuse the first-time user should be described to the user before they are encountered

    10. allow the user to select different page layout templates for presentation of pages. (e.g. 3 column, linear, adding extra orientation or navigation elements, etc.) [I#353]

Guideline 4: ROBUST. Use Web technologies that maximize the ability of the content to work with current and future accessibility technologies and user agents.

Core Checkpoints for Guideline 4

4.1 [CORE] Technologies are used according to specification.

Best Practice Measures for Checkpoint 4.1
  1. Same as item #1 above, without the exception for backward compatibility.

4.2 [CORE] Programmatic user interfaces are accessible or alternative, accessible versions are provided

Best Practice Measures for Checkpoint 4.2
  1. accessibility conventions of the markup or programming language (API's or specific markup) are used [I#331]

  2. the interface has been tested using a variety of assistive technologies and preferably real people with disabilities who use assistive technologies to determine that those assistive technologies are able to access all information on the page or hidden within the page.

Extended Checkpoints for Guideline 4

4.3 [E10] Technologies that are relied upon by the content are declared and widely available.

Best Practice Measures for Checkpoint 4.3
  1. a list of technologies and features, support for which is required in order for the content to be operable, has been determined and is documented in metadata and / or a policy statement associated with the content.

  2. technologies and features on the required list are available in at least two independently-developed implementations. (it is preferable that the technologies used for the implementations have been supported for at least one prior version of the software)