| CARVIEW |
Mock WCAG 2.0 Working Draft
17 May 2001
- This version:
- https://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20010328.html
- Latest version:
- https://www.w3.org/WAI/GL/WCAG20/
- Previous version:
- https://www.w3.org/TR/2001/WD-WCAG20-20010125.html
- Editors:
- Jason White, University of Melbourne
Wendy Chisholm, W3C
Gregg Vanderheiden, Trace R&D Center
This WAI Glossary is dedicated to the Memory of Len Kasday
Copyright 2000 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document useand software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
Status
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 based on consensus of the WCAG Working Group nor has it gone through W3C process thus it in no way supersedes the checkpoints in WCAG 1.0.
Several edits have been made to the document and have been marked as "[Proposed]." Once these have been reviewed and accepted by the WCAG Working Group they will be marked as "[New]" for a couple of drafts thereafter.
Please refer to "Issue Tracking for WCAG 2.0" 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.
Please send comments on this document to w3c-wai-gl@w3.org. The archives for this list are publicly available.
Contents
- Status Of This Document
- Contents
- Introduction
- Who Benefits ?
- How These Guidelines Are Organised
- The Guidelines and
Their Checkpoints
- Guideline 1. Presentation
- Guideline 2. Interaction
- Guideline 3. Comprehension
- Guideline 4. Technology Considerations
- Glossary
- Contributors
Introduction
Purpose
These guidelines outline the design principles that allow the usable, attractive, and functional web site to become more accessible to people with disabilities. When these principles are ignored, individuals with disabilities may not be able to access the content at all, or they may be able to do so only with great difficulty. When these principles are employed, by default they also make Web content accessible to a variety of powerful new web-enabled devices, such as cellphones, PDA's, kiosks, WebTV Add all devices. As well as making that content accessible to people using those devices in a wide variety of situations. (Have you ever read the captions on a TV in a store, because the background noise made it difficult to hear?) Web site designers can make a difference in the lives of millions of people by employing these principles in their own design.
Who Benefits ?
Individuals With Disabilities
- Visual Disabilities:
- Blindness: Accountant
- Low Vision
- Color Blindness: Shopper
- Hearing Disabilities:
- Deafness: Online Student
- Hard of Hearing
- Physical Disabilities:
- Neuro-muscular (Motor): Reporter
- Skeletal
- Speech Disabilities
- Cognitive and Neurological Disabilities:
- Impairments of Intelligence: Clerk
- Memory Impairments
- Mental Health Disabilities
- Learning Disabilities:
- Dyslexia, or Dyscalculia: Classroom Student
- ADD, and ADHD
- Seizure Disorders
- Multiple Disabilities: Teenager
- Age Related Conditions: Retiree
Individuals Without Disabilities
Individuals without disabilities also benefit from these guidelines. Those without disabilities may find themselves in situations that limit their ability to use certain abilities. For example, Web content that is accessible to the deaf will also benefit those who, for whatever reason, cannot hear sounds at that moment (e.g. the computer has no speakers, or the person is using a portable Web-enabled device in a public environment where noises would be inappropriate, etc.). Likewise, Web content that is accessible to the blind through synthesized speech software is also accessible to individuals who cannot afford to be visually distracted (e.g. individuals using Web-enabled devices in their cars).
Broad Nature
The principles in these guidelines represent broad, inclusive concepts that apply to all Web-based content, and not just to HTML, XML, or any other specific technology. The inclusive nature of the guidelines is purposefully forward-thinking, to allow Web developers to apply them to a variety of situations and technologies, including those yet unforeseen. As a result, the guidelines can seem vague when applied to any single technology. For this reason, Web accessibility techniques for specific technologies (e.g. HTML, XML) have been enumerated in separate documents, which are companion documents to these guidelines.
Web Content Accessibility Guidelines Techniques Documents:
- HTML/XHTML Techniques
- XML Techniques
- PDF Techniques
- Multimedia Techniques
- Server-Side Techniques
- Javascript Techniques
- SVG Techniques
- SMIL Techniques
Optimizing Content for Specific Disability Types
Under some circumstances, the best way to make content both available and usable is to create versions of the content which have been optimized for specific disability types. In some cases, optimization may consist of nothing more than changing the presentation style?the layout or "look and feel" of an item?without changing the item itself. Server-side scripting in which the same content is served out though different templates is one method of accomplishing this result. In other cases, optimization may require the conversion of the content into a different format. Text can be simplified and condensed, or converted into a purely illustrated format, to aid those with certain cognitive disabilities, for example. Optimization is especially appropriate when individuals with a specific disability type are the primary audience of the content.
A collection of Optimization Techniques Documents has been prepared for some of the more common disability types, to aid Web developers who need or who desire to optimize their content for specific disability types. [*Author's note: Yes, I am proposing that we develop documents for this purpose. The titles in the list below are not all-inclusive, and in fact, there is a need to define them more carefully, but I will leave that until later.]
Limitations
The implementation of these guidelines will remove accessibility barriers for the majority of individuals with disabilities. Content that would otherwise be impossible to access for some people can be made available. Nevertheless, the removal of availability barriers does not always translate into the removal of usability barriers. These guidelines address some issues of disability usability, but this document is not meant to address usability issues in the fullest sense. One of the difficulties encountered when addressing the issue of usability is that different disability types sometimes benefit from contrasting usability features.
The implementation of these guidelines will remove accessibility barriers for the majority of individuals with disabilities. Content that would otherwise be impossible to access for some people can be made available. Nevertheless, the removal of availability barriers does not always translate into the removal of usability barriers. These guidelines address some issues of disability usability, but this document is not meant to address usability issues in the fullest sense. One of the difficulties encountered when addressing the issue of usability is that different disability types sometimes benefit from contrasting usability features.
A collection of Links for Optimization Techniques Documents has been prepared for some of the more common disability types, to aid Web developers who need or who desire to optimize their content for specific disability types.
Conformance
[*Paul Bohman wrote...... Author's note: I am putting some content?much of it copied from WCAG 1.0?in here as a placeholder until conformance is more thoroughly discussed]
Conformance Levels
As in Web Content Accessibility Guidelines version 1.0, each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility.
- [Priority?1]
- A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
- [Priority?2]
- A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
- [Priority?3]
- A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.
Technology Specificity
Detailed compliance criteria are enumerated in the Techniques Documents for the specific technology or category of technologies in question. [*Author's note: Here I am throwing in the assumption that the technique documents are normative, which I know is a controversial issue.]
Proposed and ControversialDisability Type Specificity
[*Author's note: Here is another controversial idea?that of having a list for different disability types with different priority levels assigned to them. I brought up this idea in the list, and my idea is explained somewhat at https://www.webaim.org/wcag/logo. The concept of conformance levels for each disability type could either be merged with or replaced by the concept of "Optimization Techniques Documents", which I mentioned above. I will leave the discussion about this item until later, however.]
Four Principle Guidelines
- Guideline 1. Presentation: Design content that allows presentation according to the user's needs and preferences
- Guideline 2. Interaction: Design content that allows interaction according to the user's needs and preferences
- Guideline 3. Comprehension: Make it as easy as possible to use and understand
- Guideline 4. Technology Considerations: Design for compatibility and interoperability
Changes From WCAG 1.0
Since the release of WCAG 1.0 in May 1999, the WCAG Working Group has received feedback on priorities of checkpoints, the usability of the set of documents, and requests for clarifications on the meaning of specific checkpoints and what is needed to satisfy them. Thus, it is intended that WCAG 2.0:
- will be more efficiently organized,
- may adjust the priority of some checkpoints,
- may modify, remove, or add requirements due to changes in Web technologies since the publication of WCAG 1.0,
- will incorporate the Errata from WCAG 1.0,
- will reflect the experience gained in implementing WCAG 1.0.
For a checkpoint by checkpoint comparison, refer to the Checkpoint Mapping Between WCAG 1.0 and WCAG 2.0 Working Draft.
Improvements in WCAG 2.0
We hope that WCAG 2.0 will have several improvements over WCAG 1.0.- More easily used with a wide range of languages
- More easily used by authoring tool developers
- Easier to determine conformance
When WCAG 1.0 was written, most of the Web used HTML. The guidelines were designed with that in mind, and applying the guidelines to other Changed from "languages" to technologies has identified some areas that can be improved. The new version should be easier to apply to a wider range of languages and content types.
The Authoring Tool Accessibility Guidelines rely heavily on WCAG to define how to make Web content accessible. Simplifying the guidelines will improve their usability for this important group.
In WCAG 1.0 there were a number of checkpoints that began "until user agents...". In the new version there are no such checkpoints. This reduces the confusion as to when a checkpoint has been met as well as the resource commitment required to keep the information produced up to date.
How These Guidelines Are Organised
This WCAG 2.0 Working Draft does not assign priorities to checkpoints, nor does it include links to technology-specific examples and techniques. Later versions of this document will assign priorities and will link to techniques. This Working Draft presents an initial reorganization and begins to incorporate other feedback received since the publication of WCAG 1.0 in May 1999.
In some cases, WCAG 1.0 checkpoints of various priorities are combined into a single checkpoint in the WCAG 2.0 Working Draft. In these instances, a priority can not be assigned to the new checkpoint until the WCAG Working Group has extensively discussed the priority for that checkpoint. Priorities will be included in a future Working Draft.
The WCAG Working Group is proceeding carefully to minimize substantial differences between the WCAG 1.0 Recommendation and the WCAG 2.0 Working Draft. Refer to the Checkpoint Mapping Between WCAG 1.0 and WCAG 2.0 Working Draft for more detail on current correspondences.
WCAG 1.0 is accompanied by supporting techniques documents (non-normative) which include examples of how to implement WCAG 1.0 in HTML and CSS. The WCAG Working Group will continue to develop the HTML and CSS technique documents as well as create new documents for other languages such as SMIL and SVG. Links to these documents will be added in future versions of the WCAG 2.0 Working Draft.
The Guidelines and Their Checkpoints
Guideline 1. Presentation:
Design content that allows presentation according to the user's needs and
preferences
The pieces of the puzzle can either be put together by the user's client, by your server, by something in between, or a mix of all of these.
User needs and preferences are determined by:
- User capabilities: sight, hearing, movement, comprehension, accessing information only visually, only auditorily, only tactilely, or through some combination of audio, visual, and tactile.
- Device and user agent capabilities: screen size, interaction methods such as: interacting with information using only a keyboard (i.e. without a mouse), only through voice, without voice, or using an assistive technology.
For more information about user capabilities, device capabilities, assistive technologies, and usage scenarios refer to the Working Draft " How People with Disabilities Use the Web."
1.1 Provide a text equivalent for all non-text
content.
A text equivalent
- Communicates the same information as the non-text content.
- Serves the same function as the non-text content.
- May contain structured content or metadata.
- May be easily converted to braille or speech, or displayed in a larger font or different colors. Thereby providing access to the information for someone who can not see at all, who can not see well, or who needs to supplement visual information with auditory information.
Depending on the purpose and content of the non-text content, a short label may be appropriate while in other circumstances, a more thorough explanation may be required.
Non-normative examples:
- Example 1. a short label
A right arrow icon is used to link to the next slide in a slideshow. The text equivalent is "Next". - Example 2. a short label and a longer explanation: A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Graph of the numbers of widgets sold in June, July, and August." The longer explanation provides the data presented in the chart.
- Example 3. a short label and a longer explanation: An animation shows how to tie a knot. The short label says, "An animation showing how to tie a square knot." The longer explanation describes the hand movements needed to tie the knot.
The need for synchronized text equivalents applies to multimedia presentations that include both audio and video tracks. If one of the tracks (either the audio or the video) does not present any significant information, then a synchronized equivalent does not need to be synchronized. However, a text equivalent, such as a text transcript, is still required. Refer to checkpoint 1.1.
- When text equivalents of auditory information are synchronized with the multimedia presentation they are called "captions."
- When text equivalents of visual information are spoken aloud (either by a human or a speech synthesizer) and synchronized with the multimedia presentation they are called "auditory descriptions." Refer to checkpoint 1.3.
Commonly called an auditory description, the description is either a prerecorded human voice or a synthesized voice that has either been prerecorded or is generated as the presentation plays. The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes.
Non-normative examples
- Example 1. A clip from a movie is published on a Web site that contains a scene where a child is trying to lure an alien to the child's bedroom by laying a trail of candy. The child is talking to himself as he lays the trail, but it is not obvious when not watching the video that this is what he is doing. Therefore, a short description is interspersed with the child's talking that says "Charlie lays a piece of candy on each stair leading to his room." Similar descriptions are included throughout the rest of the clip.
- Example 2. A video clip accompanies a news story about the recent flooding in a major city. The reporter describes what is seen, for everyone. No further description is necessary.
- Example 3. An animation shows a clown slipping on a banana and falling down. There is no audio track for this animation. No synchronized description is required. Instead, provide a static description according to checkpoint 1.1.
The logical structure of content represents changes in context. For example,
- A book is divided into chapters, paragraphs, lists, etc. Chapter titles help the reader anticipate the meaning of the following paragraphs. Lists clearly indicate separate, yet related ideas. An italicized phrase emphasizes an important idea. All of these divisions help the reader anticipate changes in context.
- A theatrical play is divided into scenes and acts. The curtain lowering, characters leaving the stage, or a short burst of music are a few ways to highlight changes in context during a play.
- A bicycle is divided into wheels and a frame. Further, a wheel is divided into a tire and a rim. In an image of the bicycle, one group of circles and lines becomes "wheel" while another group becomes "frame."
When the logical structure is documented in markup or a data model,
- a reader may use software to jump between changes in context. For example, a reader could jump from chapter title to chapter title in the book, between scenes in the play, or between parts of the bicycle.
- a reader may change how chapter titles are displayed or how text is emphasized, based on their personal preferences.
- the content can be presented on a variety of devices because the device software can choose only those elements of the content that it is able to display and display them in the most effective way for that device.
1.5 Using appropriate markup, define the natural language of each document, indicating any changes.
Since a document is made up of several pieces of content, if the language differs between pieces, they should each be marked up.
1.6 Separate content and structure from presentation.Content and presentation can be separated because the rules that control how content is displayed can be separated from the markup that denotes the structure of the content.
Typically, style rules are stored separately from the content to which they apply, in resources which are referred to in these guidelines as style sheets. To facilitate the presentation of Web content by a range of devices (high and low-resolution displays, printers, speech devices, etc.), it is advisable to associate a variety of style sheets with your Web content.
Guideline 2. Interaction:
Design content that allows interaction according to the user's needs and
preferences
Proposed
2.1 Provide more than one path or method to find
content.
One of the most basic features of the Web is to interact with information. The most common form of interaction is navigating - to make your way through Web space to find a particular story, article, person, etc. Providing more than one navigation method helps users choose the most comfortable path or style of navigation. Navigation methods include:
- a table of contents,
- a site map,
- an index,
- menus or navigation bars,
- a link that jumps over navigation links and positions the user at the beginning of the primary content on the page,
- image maps,
- a search function.
2.2 Provide consistent responses to user actions.
Providing responses to user actions is important feedback for the user. This lets them know that your site is working properly and encourages them to keep interacting. When the user receives an unexpected response, they might think something is wrong or broken. Some people might get so confused they will not be able to use your site. Common responses to user actions:
- rollover effects,
- popup menus,
- submitting a form after the user activates the submit button,
These actions should be predictable and sensible to the end user; this is achieved by making the interactions consistent, both within the site and with commonly used models of computer interaction.
2.3 Give users control of mechanisms that cause extreme changes in context.
Mechanisms that cause extreme changes in context include:
- opening a new browser window,
- frames that do not track history making the "back" button of most browsers useless.
This can be satisfied by providing an option to deactivate the changes in context. User agents may also offer control over this effect
.
2.4 Give users control over how long they can spend reading or interacting with content.
Mechanisms that required a timed response include:
- automatic refresh
- redirection
- flicker
- blinking
This can be satisfied by providing an option to deactivate automatic updating, or to control the rate at which it occurs. User agents may also offer control over this effect. Note that flicker effects can cause seizures in people with photoepilepsy.
Proposed
2.5 Use device-independent event handlers.
When writing scripts or applications that have a user interface, ensure that the interface may be used with any type of input device. For example, if a user interface control can be activated by a mouse click it should also be activated by a keyboard event such as pressing the Enter key.
Guideline 3. Comprehension:
Make it as easy as possible to use and understand
3.1 Use consistent presentation.
Consistency helps users determine the relationships between items in the content. This ability to understand the structure helps users navigate, orient themselves, and thus understand.
3.2 Emphasize structure through presentation, positioning, and labels.
Emphasizing the structure through presentation will help the user
- orient himself or herself within the document,
- focus on important content,
- allow the author to highlight key ideas within the context of
supplementary text.
.
If the default presentation of the structured content does not meet the needs of your audience use graphics, colors, sounds, etc. to emphasize the structure. For example, section headings may appear in a different color and spoken in a different voice than the rest of the text. However, ensure that the structural and semantic distinctions are captured in the markup (checkpoint 2.3).
- Identify important topics or subdivisions within a document (e.g., in XHTML use the Hn elements, identify groups of user interface controls).
- Identify important groupings of data (e.g., label groups of rows or columns with a header),
- In addition to full, descriptive labels, it may also be appropriate to provide abbreviated labels to be used when displaying content on small displays or via speech output. For example, an abbreviated heading for a column of data.
This checkpoint addresses the need to facilitate comprehension of the content by all readers, especially those with cognitive disabilities. It should not be interpreted as discouraging the expression of complex or technical ideas. However, authors should strive for clarity and simplicity in their writing.
3.4 Use multimedia to illustrate concepts.
Sounds, graphics, videos and animations can help make a concepts presented
in a Web site easier to understand, especially for people with cognitive
disabilities or those who are unfamiliar with the language of the text of the
site. Material provided in auditory or visual forms must also be available as
text (see Guideline 1).
For example, this image tries to represent the idea that a text equivalent
equals its non-text equivalent as described in Checkpoint 1.1.
[D]
Examples of complex information:
- data tables,
- concepts that are esoteric or difficult to understand,
- content that involves several layers.
Content is considered complex if the relationships between pieces of information are not easy to figure out. If the presentation of the information is intended to highlight trends or relationships between concepts, these should be explicitly stated in the summary.
3.6 Define key terms, abbreviations, acronyms, and specialized language.
Defining key terms and specialized language will help people who are not familiar with the topic you are presenting. Providing the expansion of abbreviations and acronyms not only helps people who are not familiar with the abbreviation or acronym but can clarify which meaning of an abbreviation or acronym is appropriate to use. For example, the acronym "ADA" stands for both the American with Disabilities Act as well as the American Dental Association.
3.7 Divide information into smaller, more manageable units.
For example,
- Divide user interface controls into logically organized groups.
- Paragraphs and sections should have clear, accurate, and informative headers. Limiting each paragraph to one main idea will help people process the information.
- Use headings, paragraphs, lists etc., appropriately to communicate relationships among items, topics or ideas.
Guideline 4. Technology Considerations:
Design for compatibility and interoperability
4.1 Choose languages, API's, and protocols that support
the use of these guidelines.
Markup languages, multimedia formats, software interface standards, etc., vary in their support of accessibility. When choosing which technologies to use, consider how easy it is apply these guidelines. Where feasible, favor technologies that:
- permit equivalents to be associated with or synchronized with auditory, graphical, and multimedia content;
- allow the logical structure of the content to be defined independently of presentation;
- support device-independence;
- are documented in published specifications and can be implemented by user agent and assistive technology developers;
- are supported by user agents and assistive technologies.
This checkpoint requires
- that markup conforms to the validity tests of the language (whether it be conforming to a schema, DTD, or other tests described in the specification), and
- that structural elements and attributes are used as defined in the specification. For example, do not use structural elements for purposes of presentation. Likewise, do not use presentation elements for purposes of structure.
Use standard software conventions to control the behaviour and activation of user interface components. Platform-specific guidance may be available for your operating system or application environment.
Proposed
4.4 Design content so that when presentation effects
are turned off or not supported the content is still usable.
Ensure that when stylistic or scripting technologies are not supported or turned off the content is still usable and readable by the user. This only applies to technologies that associate presentation with structure.
This may be accomplished by providing:- metadata,
- a transformation filter,
- a mechanism to enable the content to be processed by the user, or
- multiple versions of the same content in order to ensure backward compatibility.
In determining the extent to which older technologies should be supported, keep in mind that:
- assistive hardware and software are often slow to adapt to technical advances.
- for significant groups of users, it may not be possible to obtain the latest software or the hardware required to operate it.
Glossary
- Auditory description
- An auditory description is either a prerecorded human voice or a synthesized voice that has either been prerecorded or is generated as the presentation plays. The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes.
- Data Model
- Not yet defined.
- Document As Proposed by Gregory R. 01-05-20
- .....for the purposes of this document, the term "document" encompasses "documents rendered from a single source file" to "reusable fragments of marked-up content, which, when rendered as part of a 'document instance', combine to produce the end-user experience of interacting with a single document", etc., only more clearly articulated and more precisely stated...
- Document ATAG 1.0 01-05-20
- A "document" is a series of elements that are defined by a markup language (e.g., HTML 4 or an XML application).
- Equivalent
- Not yet defined.
- Markup
- Not yet defined.
- Multimedia
- Not yet defined. The definition must include the idea of timelines and slide shows (per 30 November 2000 telecon)
- Normative / Non-normative
- Throughout this document we refer to several "non-normative" examples. These are included to help readers understand concepts. Normative items are prescriptions for what must/should/may be done to create accessible content.
- Presentation
- Not yet defined.
- Semantics
- Not yet defined.
- Transform Gracefully
- Not yet defined.
Contributors
Regular participants of the WCAG Working Group:
Bruce Bailey, Kynn Bartlett, Dick Brown, Jonathan Chetwynd, Wendy Chisholm, Alan J. Flavell, Al Gilman, Katie Haritos-Shea, Donovan Hipke, Ian Jacobs, Marshall Jansen, Leonard Kasday, William Loughborough, Charles McCathieNevile, Marti McCuller, Matt May, Robert Neff, Sean B. Palmer, Anne Pemberton, Loretta Guarino Reid, Gregory J. Rosmaita, Lisa Seeman, Cynthia Shelly, Andi Snow-Weaver, Gregg Vanderheiden, Jason White
Other contributors:
Dan Aunspach, Harvey Bingham, Judy Brewer, Dan Brickley, David Clark, Michael Cooper, Nir Dagan, Daniel Dardailler, Geoff Freed, Greg Gay, Jon Gunderson, Shawn Lawton Henry, Chuck Hitchcock, Phill Jenkins, Chris Kreussling, Chuck Letourneau, Greg Lowney, Scott Luebking, Lisa Kestenbaum, Marja-Riitta Koivunen, Masafumi NAKANE, Tim Noonan, Anuska Perkins, David Poehlman, Chris Ridpath, Greg Rosenberg, Heather Swayne, David Tanner, Jim Thatcher, Claus Th?gersen, Peter Verhoeven, Cynthia Waddell, Mike Williams
$Date: 2001/08/16 01:09:31 $ Katie Haritos-Shea