Copyright © 2003 W3C ® ( MIT , ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
NOTICE:
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.
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.
non-text content that can not be expressed in words has a text equivalent for all aspects that can be expressed in words.
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.
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/."
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.
captions and audio descriptions are provided for all live broadcasts.
the presentation does not require the user to read captions and the visual presentation simultaneously in order to understand the content.
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]
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.
the structural emphases are chosen to be distinct on different major visual display types (e.g. black and white, small display, mono audio playback).
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.
for visual presentations, font variations, styles, size and white space can be used to emphasize structure.
color and graphics can be used to emphasize structure.
for auditory presentations, different voice characteristics and/sounds can be used for major headings, sections and other structural elements.
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.
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.
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.
any moving content can be frozen using the keyboard[I#325]
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."
animation or other content does not visibly or purposely flicker between 3 and 49 Hz.
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.
the content has been reviewed, taking into account the following strategies for facilitating orientation and movement, applying them as appropriate.
breaking up text into logical paragraphs
providing hierarchical sections and titles, particularly for longer documents
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
dividing very large works into sections and or chapters with logical labels
others?
information is provided that would allow an assistive technology to determine at least one logical, linear reading order.
diagrams are constructed in a fashion so that they have structure that can be accessed by the user.
where possible, logical tab order has been created.[I#319]
where possible, the user is allowed to select from a list of options as well as to generate input text directly
errors are identified specifically and suggestions for correction are provided where possible
checks for misspelled words are applied and correct spellings are suggested when text entry is required.
where consequences are significant and time-response is not important, one of the following is true
actions are reversible
where not reversible, actions are checked for errors in advance
where not reversible, and not checkable, a confirmation is asked before acceptance
Editorial Note: The CKW reorganization suggested that this checkpoint be combined with checkpoint 1.4. [I#442]
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]
the content has been reviewed, taking into account the following strategies for determining the definition of abbreviations and acronyms, applying them as appropriate.
provide a definition or link (with the first occurrence) of phrases, words, acronyms, and abbreviations specific to a particular community.
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.
if contracted forms of words are used such that they are ambiguous, provide semantic markup to make words unique and interpretable.
the content has been reviewed, taking into account the strategies for evaluating the complexity of the content, applying them as appropriate.
Strategies for evaluating the complexity of the content include:
use of sentence structures that increase understanding
such as active voice in languages where this form helps convey information
length of noun phrases
strings of no more than three or four nouns are easiest to understand
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."
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"
complexity of verb tenses
do the tenses used in a document seem overly complicated?
intelligibility of verb phrases
familiarity of idioms or slang
logic in the order and flow of information
consequences of ambiguity or abstraction
improved readability of vertical lists might offer in place of long paragraphs of information
use of summaries to aid understanding
thoroughness in the explanation of instructions or required actions
consistency in the use of names and labels
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)
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
testing with potential users for ease of accessibility
use of a controlled language
providing support for conversion into symbolic languages
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.
user can select a different location for navigation elements in the layout of the page.[I#352]
the content has been reviewed, taking into account common ideas for making content consistent and predictable, applying them as appropriate.
common ideas for making content consistent and predictable indclude:
place navigation bars in a consistent location whenever possible
similar layout for user interface components should be used for sections or whole site
similar user interface components should be labeled with similar terminology
use headers consistently
use templates for consistent presentation of sections or whole site
pages with similar function should have similar appearance and layout
controls that look or sound the same should be designed to act the same
conventions likely to be familiar to the user should be followed
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
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]
accessibility conventions of the markup or programming language (API's or specific markup) are used [I#331]
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.
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.
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)