W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2002

Retry: RE: Request for Review: WCAG 2.0 Working Draft

From: Weinland, Audrey <audrey.weinland@sap.com>
Date: Thu, 31 Oct 2002 20:42:17 -0500
Message-Id: <5.1.0.14.2.20021031204136.02519ec0@localhost>
To: w3c-wai-gl@w3.org
Dear Working Group members,

Thank you for giving us the opportunity to comment on the draft WCAG 2.0 
guidelines. The Accessibility Competence Center team at SAP has reviewed 
the draft and we provide our comments below. We have both general comments, 
which appear above the guidelines, and specific comments, which we've 
entered directly in the body of the guidelines document. Our comments 
appear in red and are preceded and followed by three asterisks (***).

Regarding the overall questions that were posed:

1. In general, is this WCAG 2.0 Working Draft easy to understand? Please 
identify sections or phrases that are difficult to understand. Please 
suggest alternative wording for us to consider.

Overall, the structure of the draft is easy to understand. Wherever we had 
difficulty with certain sections or phrases, we have indicated that 
directly in the document.

2. The priority structure of this WCAG 2.0 Working Draft differs from WCAG 
1.0. Is this structure easy to understand? Would it be effective?

We have made some comments about the priority structure in the Conformance 
section of the document. In general, however, we do feel that this priority 
structure is not difficult to understand.

3. If your site already uses WCAG 1.0, do you think it would be difficult 
to migrate from WCAG 1.0 to WCAG 2.0? What would make it easier? Please 
note that supporting documents, such as technology-specific techniques 
documents, are not yet available. We look forward to your comments specific 
to Web applications, as we discussed at CSUN this year.

SAP Web applications already target WCAG 1.0, Priority 1 guidelines. We 
have been considering targeting conformance with WCAG 1.0, Priority 2 
guidelines in the near future.

In our assessment, it would not be a simple matter to migrate our Web 
applications from WCAG 1.0, Priority 1, to WCAG 2.0, Level 1. A document 
that maps WCAG 1.0 guidelines to their counterparts in WCAG 2.0 would be 
helpful, although we realize there will often not be a 1-to-1 mapping. 
Overall, we feel that the inclusion of so many more usability-oriented 
guidelines will make the task of conforming to WCAG 2.0, Level 1 more 
difficult than conforming to WCAG 1.0, Priority 1. However, we will have a 
better idea of the difficulty once we see the supporting documents, such as 
the technology-specific techniques documents.

Our general comments follow, and the draft document with our specific 
comments appears below them. Please let us know if you have any questions 
regarding our comments.

Regards,
SAP Accessibility Competence Center

----------------------------------------------------------------------------
***General Comments:

SAP reviewed this draft with an eye specifically towards our own products, 
which are Web-based applications (called "Web apps" below). In general, we 
feel that these guidelines have Web sites in mind and are not always 
applicable to our kind of Web-based software. For example, the Purpose 
section states that the document "outlines design principles for creating 
accessible Web sites." Other specific instances are noted in the comments 
below. It is important that Web applications be taken into consideration, 
because the WCAG guidelines are used in many countries and U.S. states as 
the basis for legal requirements for accessibility for both Web sites and 
Web apps.

It was not entirely clear whether documents are covered by these 
guidelines, meaning file formats like Powerpoint files (.PPT), Word 
document files (.DOC), Adobe files (.PDF), etc. If not, they should be, 
since most Web sites and even Web apps often include documents in non-HTML 
formats.

The multimedia definition does not cover animation. Is it considered not 
part of multimedia?

For every Level 2 criteria about posting a statement: Where do you put all 
of the site-wide statements? And where do you put the page-specific 
statements? Won't these add a lot of noise?

There appear to be many checkpoints that are focused on usability, not 
accessibility per se. It would be good if the guidelines included a 
definition of accessibility. In our opinion, if the user can get to it, 
find out what it is, and activate it, we consider it accessible. The 
primary focus should really be on whether the user can complete the 
task/function. How *easy* it is to use, or how quick it is to find or use 
it, in our opinion belongs in the realm of usability, not accessibility. 
For example, a Web application may be produced quickly and not be easily 
usable by anybody, disabled or non-disabled. Following these guidelines 
would force the company to make it easy to use. Should that really be the 
intention of these guidelines? We don't think so, particularly considering 
the fact that many U.S. states use the WCAG guidelines as the basis for 
their legal requirements, and this would in effect legislate usability.

The WCAG checkpoints are geared towards a much broader user base than our 
Web apps are geared towards. We have to assume a certain level of cognitive 
ability for users to use our Web apps. And since they are our customers, 
not the general public, shouldn't that be allowed? Also, the checkpoints 
seem to be geared more towards learnability than accessibility or usability 
per se, but SAP expects our users to receive training and extensive 
documentation, which should cover much of the learnability aspects already. 
Finally, we sometimes have to sacrifice some learnability in our Web apps 
in order to make the screen faster to use for trained people, i.e. for 
productivity reasons. We really need checkpoints that are focused on 
accessibility, not usability or learnability.

Are issues raised by page refresh covered in these guidelines? We couldn't 
find anything about that.

Do these guidelines apply equally to mobile Web applications, like those 
that might run on a cell phone?***



Web Content Accessibility Guidelines 2.0




W3C Working Draft 22 August 2002

This version:
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/>http://www.w3.org/TR/2002/WD-WCAG20-20020822/ 

Latest version:
<http://www.w3.org/TR/WCAG20/>http://www.w3.org/TR/WCAG20/
Previous version:
<http://www.w3.org/TR/2001/WD-WCAG20-20010824/>http://www.w3.org/TR/2001/WD-WCAG20-20010824/ 

Editors:
Ben Caldwell, Trace R&D Center
Wendy Chisholm, W3C
Jason White, University of Melbourne
Gregg Vanderheiden, Trace R&D Center
<http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright>Copyright 
2002 <http://www.w3.org/>W3C  (<http://www.lcs.mit.edu/> MIT, 
<http://www.inria.fr/>INRIA, <http://www.keio.ac.jp/>Keio), All Rights 
Reserved. W3C 
<http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer>liability, 
<http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks>trademark, 
<http://www.w3.org/Consortium/Legal/copyright-documents-19990405>document 
use and 
<http://www.w3.org/Consortium/Legal/copyright-software-19980720>software 
licensing rules apply.

----------


Abstract

W3C published the <http://www.w3.org/TR/WCAG10/>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 prepared by the <http://www.w3.org/WAI/GL/>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 
<http://www.w3.org/TR/WCAG10/>WCAG 1.0.

Please refer to "<http://www.w3.org/WAI/GL/wcag20-issues.html>Issue 
Tracking for WCAG 2.0 Working Draft" for a list of open issues related to 
this Working Draft. The 
"<http://www.w3.org/WAI/GL/WCAG20/change-history.html>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 <http://www.w3.org/TR/>current W3C Recommendations and other 
technical documents is available.

The Working Group welcomes comments on this document at 
<mailto:w3c-wai-gl@w3.org>w3c-wai-gl@w3.org. The 
<http://lists.w3.org/Archives/Public/w3c-wai-gl/>archives for this list are 
publicly available.

Patent disclosures relevant to this specification may be found on the WCAG 
Working Group's <http://www.w3.org/WAI/GL/disclosures.html>patent 
disclosure page in conformance with W3C policy.

This document has been produced as part of the W3C 
<http://www.w3.org/WAI/>Web Accessibility Initiative (WAI). The goals of 
the WCAG WG are discussed in the 
<http://www.w3.org/WAI/GL/new-charter-2000.html>Working Group charter. The 
WCAG WG is part of the <http://www.w3.org/WAI/Technical/Activity>WAI 
Technical Activity.

----------


Table of Contents

    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#intro>Introduction
        * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#intro-purpose>Purpose
        * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#how-to>How to read 
this document
        * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#audience>Audience
        * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#scope>Scope
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#priorities-techs>Priorities 
and Techniques
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#conformance>Conformance
    * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#overview-design-principles>Overview 
of Design Principles
    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#presentation>Guideline 
1 - Perceivable. Ensure that all intended function and information can be 
presented in form(s) that can be perceived by any user - except those 
aspects that cannot be expressed in words.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#text-equivs>Checkpoint 1.1 
For all non-text content that can be expressed in words, provide a text 
equivalent of the function or information the non-text content was intended 
to convey.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#time-based>Checkpoint 1.2 
Provide synchronized media equivalents for time-dependent presentations.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#use-style>Checkpoint 1.3 
Make all content and structure available independently of presentation.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#color-contrast>Checkpoint 
1.4 Ensure that foreground content is easily differentiable from background 
for both auditory and visual presentations.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#natural-lang>Checkpoint 1.5 
Provide information needed for unambiguous decoding of the characters and 
words in the content.
    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#operation>Guideline 2 
- Operable. Ensure that the interface elements in the content are operable 
by any user.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#device-indie-events>Checkpoint 
2.1 Ensure that all of the functionality of the content is operable through 
character input to the content or user agent.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#avoid-interfering>Checkpoint 
2.2 Allow users to control any time limits on their reading, interaction or 
responses unless control is not possible due to the nature of real-time 
events or competition.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#avoid-flicker>Checkpoint 2.3 
Avoid causing the screen to flicker.
    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#navigation>Guideline 3 
- Navigable. Facilitate content orientation and navigation
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#logical-structure>Checkpoint 
3.1 Provide structure within content.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#use-style-to-emphasize>Checkpoint 
3.2 Emphasize structure through presentation(s), positioning, and labels.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#nav-mech>Checkpoint 3.3 
Provide multiple methods to explore sites that are more than two layers deep.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#consistency>Checkpoint 3.4 
Use consistent but not necessarily identical presentation.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#consistent-responses>Checkpoint 
3.5 Provide consistent and predictable responses to user actions.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#consistent-behaviors>Checkpoint 
3.6 Provide methods to minimize error and provide graceful recovery.
    * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#comprehension>Guideline 4 - 
Understandable. Make it as easy as possible to understand the content and 
controls.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#clear-and-simple>Checkpoint 
4.1 Write as clearly and simply as is [appropriate / possible] for the 
purpose of the content.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#supplement-text>Checkpoint 
4.2 Supplement text with non-text content.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#provide-overview>Checkpoint 
4.3 Annotate complex, abbreviated, or unfamiliar information with summaries 
and definitions.
    * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#interoperability>Guideline 5 
- Robust. Use Web technologies that maximize the ability of the content to 
work with current and future accessibility technologies and user agents.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#use-markup-correctly>Checkpoint 
5.1 Use technologies according to specification.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#new-tech-degrade>Checkpoint 
5.2 Design for backward compatibility.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#wcag-possible-lang>Checkpoint 
5.3 Choose technologies that are designed to support accessibility.
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#AT-compatible-UI>Checkpoint 
5.4 Ensure that user interfaces are accessible or provide an accessible 
alternative.
    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#glossary>Appendix A: 
Glossary
    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#contributors>Appendix 
B: Contributors
    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#diff-versions>Appendix 
C: The differences between WCAG 1.0 and WCAG 2.0
        * 
<http://www.w3.org/TR/2002/WD-WCAG20-20020822/#improvements>Improvements in 
WCAG 2.0
    * <http://www.w3.org/TR/2002/WD-WCAG20-20020822/#references>Appendix D: 
References

----------


Introduction




Purpose

This document outlines design principles for creating accessible Web sites. 
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, they also make Web 
content accessible to a variety of Web-enabled devices, such as phones, 
handheld devices, kiosks, network appliances, etc. By making content 
accessible to a variety of devices, that content will also be accessible to 
people in a variety of situations.

The design principles in this document represent broad concepts that apply 
to all Web-based content. They are not specific to HTML, XML, or any other 
technology. This approach was taken so that the design principles could be 
applied to a variety of situations and technologies, including those that 
do not yet exist.


How to read this document

In order to facilitate understanding of the guidelines and to help people 
focus in on just the parts they need, the guidelines are presented as a set 
of interrelated documents. There are basically 3 layers to the guidelines 
information.


1 - Top layer - Overview of Design Principles, Guidelines, Checkpoints

The top layer is titled "Web Content Accessibility Guidelines 2.0". It is 
the document you are currently reading. This document provides:
    * An introduction
    * The 5 major Guidelines for accessibility (Perceivable, Operable, 
Navigable, Understandable and Robust).
    * The (non-technology-specific) checkpoints for each guideline (21 in 
total).
    * Success criteria (normative), and definitions, benefits and examples 
(all non-normative) for each checkpoint
    * An appendix containing definitions, references and other support 
information.



2 - Technology-specific Checklists

In addition to the general guidelines, there will be a series of 
technology-specific checklist documents. These documents will provide 
information on what is required when using different technologies in order 
to meet the WCAG 2.0 Working Draft access guidelines.

Reviewer's Note: These checklists do not yet exist. At the present time the 
checklists are expected to be non-normative, though no formal decision has 
been made.


3 - Bottom layer - Technology-specific application information

The Techniques Documents will include code examples, screen shots, and 
other information specific to a technology. These documents will be 
non-normative. They will contain different strategies for meeting the 
requirements as well as the current preferred approaches where they exist. 
Examples include:
    * Hypertext Markup Language (HTML) and Extensible Hypertext Markup 
Language (XHTML(tm)) Techniques
    * Cascading Style Sheets (CSS) Techniques
    * Server-side scripting Techniques
    * Client-side scripting Techniques
    * Scalable Vector Graphics (SVG) Techniques
    * Synchronized Multimedia Integration Language (SMIL) Techniques
    * Extensible Markup Language (XML) Techniques
(These will become active links as the corresponding working drafts are 
published)


Audience

These guidelines have been written to meet the needs of many different 
audiences from policy makers, to managers, to those who create Web content, 
to those who code the pages. Every attempt has been made to make the 
document as readable and usable as possible while still retaining the 
accuracy and clarity needed in a technical specification. For first time 
users, the work of the <http://www.w3.org/WAI/EO/>Education and Outreach 
Working Group of the Web Accessibility Initiative is highly recommended.


Scope

The guidelines cover a wide range of issues and recommendations for making 
Web content more accessible. They include recommendations to make pages 
accessible and usable by people with a full range of disabilities. In 
general, the guidelines do not include standard usability recommendations 
except where they have specific ramifications for accessibility beyond 
standard usability impacts.


Priorities and Techniques

This WCAG 2.0 Working Draft does not assign priorities to checkpoints, as 
did WCAG 1.0. Instead, each of the checkpoints has levels of implementation 
listed for it. There are 3 levels labeled "Minimum", "Level 2", and "Level 
3". The main WCAG 2.0 Working Draft document does not include 
technology-specific implementation requirements or techniques, but it does 
include links to technology-specific requirements as well as 
technology-specific examples and techniques.

This Working Draft of WCAG 2.0 is a follow-on and evolution of WCAG 1.0 and 
reflects feedback received since the publication of WCAG 1.0 in May 1999. 
Although the same approaches to accessibility are followed in 1.0 and 2.0, 
the organization and structure have been improved significantly.

The Web Content Accessibility Guidelines Working Group is working carefully 
to enable organizations and individuals that are currently using WCAG 1.0 
(which remains stable and referenceable at this time) to ensure that they 
will eventually be able to make a smooth transition to WCAG 2.0. To 
understand how this eventual transition would be facilitated, please refer 
to the (draft) 
<http://www.w3.org/WAI/GL/WCAG20/2002/08/20-mapping.html>Checkpoint Mapping 
Between WCAG 1.0 and the WCAG 2.0 Working Draft for more detail on current 
correspondences.


Conformance

In order to claim any conformance to the guidelines it is necessary to 
satisfy the "MINIMUM" success criteria of every checkpoint. The minimum 
criteria represent those aspects of the checkpoint requirements which, in 
the absence of a full implementation, will nonetheless offer substantial 
benefit to people with disabilities by removing barriers that would 
otherwise make it difficult or impossible to access the content. The Level 
2 and Level 3 criteria build upon this functionality, making the content 
accessible to people who would not be able to access it, or could do so 
only with substantial difficulty, if only the minimum criteria had been met.

Sites which go beyond the Minimum level of conformance can claim 
conformance at higher levels in several ways.
    * If they meet all of the criteria for Level 2 or Level 3 ***in 
addition to Level 1***  they can claim conformance at those levels.
    * If they meet some but not all of the criteria for Level 2 ***in 
addition to Level 1*** then can claim conformance at Level 1+.
    * If they meet all of the criteria for level 2 and some but not all of 
the criteria for Level 32 ***in addition to Level 1***  then can claim 
conformance at Level 2+.
    * It is possible and recommended that sites report specifically which 
criteria they have met within each of the guidelines and checkpoints. This 
can be done using [Reviewer's Note: method not yet defined]. ***Like a VPAT 
or a checklist of some sort? This is a key issue for us, since it's not 
easy to figure out where or how to report this information in a Web app.***
***How do you ensure that you've satisfied a criterion? Are you supposed to 
guarantee that every page conforms? What is the method of testing/coverage 
required?
Also, if you do Level 3 for a checkpoint, but you don't do Levels 1 or 2, 
could you claim that you're compliant with Level 3?***


Overview of Design Principles

The overall goal is to create Web content that is perceivable, operable, 
navigable, and understandable by the broadest possible range of users and 
compatible with their wide range of assistive technologies, now and in the 
future.
    * Perceivable. Ensure that all content can be presented in form(s) that 
can be perceived by any user - except those aspects of the content that 
cannot be expressed in words.
    * Operable. Ensure that the interface elements in the content are 
operable by any user.
    * Navigable. Facilitate content orientation and navigation
    * Understandable. Make it as easy as possible to understand the content 
and controls.
    * ***We feel this is more of a usability issue, not an accessibility 
issue. In fact, the guidelines in this section seem to require that pages 
be intuitive. That would be a difficult requirement for some Web apps to 
meet, since they can be complex due to the nature of the task being 
performed. And it brings up the question of where training fits in. Users 
generally need training before they can use Web apps, and that training 
provides much of the understanding. Finally, how do you measure 
understandability? This could be a very subjective thing.***
    * Robust. Use Web technologies that maximize the ability of the content 
to work with current and future accessibility technologies and user agents.
    * ***It's not easy for a Web app to conform with everything on the 
market. There are currently no standards between screen readers, for 
example. Even Internet Explorer doesn't support certain standard HTML 
controls (such as the long description tag). How do we take these issues 
into account? Are there minimum requirements to work with specific 
assistive technologies? For example, would JAWS have a list of things we 
need to do to be compatible with them? We need to know what to do/what not 
to do. Wouldn't it be enough to ensure that we provide one method of access 
for each disability, as Section 508 specifies?

    * One reason SAP doesn't support all browsers is because some browsers 
don't meet our requirements in terms of things like performance, etc. We 
implement our apps in a controlled, corporate environment, not in a public 
environment. We are able to tell our customers that they need to use XYZ 
browser with SAP Web apps; it's a marketing decision whether we will target 
other browsers as well. So a guideline that mandates that we support other 
browsers does not make sense for us.***
Accessible Web content benefits a variety of people, not just people with 
disabilities. In the physical world, ramps are used by bicycles, people 
pushing strollers, and people in wheelchairs. Similarly, accessible Web 
content is usable by a variety of people with and without disabilities. For 
example, people who are temporarily operating under constrained conditions 
like operating in a noisy environment or driving their car where their eyes 
are busy. Likewise, a search engine can find a famous quote in a movie if 
the movie is captioned.

Note: These principles apply only to Web content presented to a human 
reader. A structured database or metadata collection where the data is 
intended for use by another machine and thus requires no interface lies 
outside the scope of these guidelines.


User needs

Here are a few scenarios, by no means an exhaustive list of the variations 
and types of disabilities and needs:
    * Someone who cannot hear will want to see the information normally 
presented via sound.
    * Someone who cannot see will want to hear or read through braille 
information that is usually presented visually.
    * Someone who does not have the strength to move quickly or easily will 
want to use as little movement as possible and have as much time as they 
need when operating Web interfaces.
    * Someone who does not read well may want to hear the information read 
aloud.
If Web content employs the design principles described in this document, 
then users should be able to access the content using adaptive strategies 
and assistive technologies. A screen reader is an example of an assistive 
technology that reads the page aloud. There are many other tools people 
with disabilities employ to make use of Web content. For more in-depth 
scenarios of people with disabilities using accessible and inaccessible Web 
content, please read "<http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/>How 
People with Disabilities Use the Web".


Designing Accessible Web Content

These guidelines provide the basic requirements for designing accessible 
Web content. This document is not designed to provide the background needed 
to learn about accessible Web design in a thorough or effective manner for 
those interested in learning. Readers are therefore referred to the 
<http://www.w3.org/WAI/EO/>Education and Outreach Working Group of the 
<http://www.w3.org/WAI/>Web Accessibility Initiative.

----------


Guideline 1 - Perceivable.
Ensure that all intended function and information can be presented in 
form(s) that can be perceived by any user - except those aspects that 
cannot be expressed in words.

Essential to any access to Web content is the ability of the user to have 
the information presented in a form which they can perceive.

The checkpoints under this guideline impact individuals with sensory 
disabilities by allowing the information to be transformed and presented in 
a form which they can perceive. They also impact individuals with cognitive 
and language disabilities by ensuring that the information is in a format 
that can be perceived by mainstream and assistive technologies which can 
read the content to them as well as (increasingly over time) transform and 
present it in a form which is easier for them to understand.


Checkpoint 1.1 For all non-text content that can be expressed in words, 
provide a text equivalent of the function or information the non-text 
content was intended to convey.




Success Criteria




You will have successfully met Checkpoint 1.1 at the Minimum Level if:

    * non-text content that can be expressed in words has a text-equivalent 
explicitly associated with it.
    * non-text content that can not be expressed in words has a descriptive 
label provided as its text-equivalent.
        * The text equivalent should fulfill the same function as the 
author intended for the non-text content (i.e. it presents all of the 
intended information and/or achieves the same function of the non-text 
content).
        * ***How would this be done for screen shots in online help 
documentation? It does not seem easy to implement. It would require a 
description of the screen layout. Where do you draw the line with the 
description? How do you know when it "fulfills the same function"? And who 
judges what "the author intended"? Is the company the author?***



You will have successfully met Checkpoint 1.1 at Level 2 if:

    * the site has a statement asserting that the text-equivalent has been 
reviewed and is believed to fulfill the same function as the author 
intended for the non-text content (i.e. it presents all of the intended 
information and/or achieves the same function of the non-text content).
***Meeting this criterion would require extensive effort. Text equivalents 
are entered by developers and by documentation people, and they are 
typically not reviewed after they are entered. Meeting this criterion would 
require automated plus manual checking of every text equivalent, which 
would be very resource-consuming. Is there a tolerance level here, or would 
everything have to be checked?***


You will have successfully met Checkpoint 1.1 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Definitions (informative)

A text equivalent
    * serves the same function as the non-text content was intended to serve.
    * communicates the same information as the non-text content was 
intended to convey.
    * may contain structured content or metadata.
Note: Text-equivalents should be easily convertible to braille or speech, 
displayed in a larger font or different colors, fed to language translators 
or abstracting software, etc.

Non-text content includes but is not limited to images, text in raster 
images, image map regions, animations (e.g., animated GIFs), applets and 
programmatic objects, ASCII art, scripts that present content, images used 
as list bullets, spacers, graphical buttons, sounds (played with or without 
user interaction), stand-alone audio files, audio tracks of video, and video.

***What about meaningless graphics that are only on a page for visual 
appeal? Shouldn't these somehow be marked so they won't be picked up by the 
AT (in HTML, with an empty ALT tag, for example)? Otherwise, they represent 
noise for the blind user. Also, screen readers like JAWS skip spacers that 
have no ALT tag, so why should we have to give them descriptive labels? ***


Benefits (informative)

    * Individuals who are blind, have low vision, have cognitive 
disabilities or have trouble reading text for any reason can have the text 
read aloud to them.
    * Individuals who are deaf, are hard of hearing or who are having 
trouble understanding the audio information for any reason can read the 
text presentation or have it translated and presented as sign language.
    * Individuals who are blind or deaf-blind can have the information 
presented in braille.



Examples (informative)

    * Example 1: providing a short label for a button/link.
    * A right arrow icon is used to link to the next slide in a slide show. 
The text equivalent is "Next Slide," so that what is read by a screen 
reader would be "link: Next Slide."
    * Example 2: providing a short label and a longer explanation of a data 
chart.
    * A bar chart compares how many shoes were sold in June, July, and 
August. The short label says, "Graph of the numbers of shoes sold in June, 
July, and August." The longer explanation provides the data presented in 
the chart.
    * Example 3: providing a short label and a longer explanation of an 
animation.
    * 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.
    * ***It would be better if there were a real example of the hand 
movements here. Telling how to do it and actually showing how to do it are 
very different! Give us a real example.***
    * Example 4: providing a short label and a transcript for an audio file 
that can be described in words.
    * An audio file is embedded in a Web page. The short label says, 
"Chairman's speech to the assembly." A link to a text transcript is 
provided immediately after the clip.
    * Example 5: providing a label for content that cannot be described in 
words.
    * An audio file is embedded in a Web page. The short label says, 
"Beethoven's 5th Symphony performed by the Vienna Philharmonic Orchestra."



Checkpoint 1.2 Provide synchronized media equivalents for time-dependent 
presentations.




Success criteria




You will have successfully met Checkpoint 1.2 at the Minimum Level if:

    * an audio description is provided of all visual information in scenes, 
actions and events (that can't be perceived from the sound track).
        * The audio description should include all significant visual 
information in scenes, actions and events (that can't be perceived from the 
sound track) to the extent possible given the constraints posed by the 
existing audio track (and constraints on freezing the audio/visual program 
to insert additional auditory description).
        * ***Is this point talking about replacing the existing soundtrack 
with an alternate audio, or having an alternate audio available in addition 
to the existing soundtrack?***
    * all significant dialogue and sounds are captioned
    * exception: if the Web content is real-time audio-only, if not 
time-sensitive (news, emergency, etc.), and not interactive, a transcript 
or other non-audio equivalent is sufficient.
    * ***Why is captioning considered the minimum? For non-real-time, 
wouldn't transcripts be OK? At least in cases where the video is not 
conveying majorly important information, for example if it's a video of an 
executive speaking at a conference.***
    * descriptions and captions are synchronized with the events they 
represent.
    * if the Web content is real-time video with audio, real-time captions 
are provided unless the content:
        * is a music program that is primarily non-vocal
    * if the Web content is real-time non-interactive video (e.g. a Webcam 
of ambient conditions), an accessible alternative is provided that achieves 
the purpose of the video. If the author's purpose is to provide real-time 
information, a media equivalent is provided that conforms to checkpoint 
1.1, or a link is provided to content elsewhere which conforms to 
checkpoint 1.1 (e.g. a link to a weather Web site).
    * if a pure audio or pure video presentation requires a user to respond 
interactively at specific times in the presentation, then a 
time-synchronized equivalent (audio, visual or text) presentation is 
provided.
exception: if content is rebroadcast from another medium or resource that 
complies to broadcast requirements for accessibility (independent of these 
guidelines), the rebroadcast satisfies the checkpoint if it complies with 
the other guidelines.


You will have successfully met Checkpoint 1.2 at Level 2 if:

    * the site has a statement asserting that the audio description has 
been reviewed and it is believed to include all significant visual 
information in scenes, actions and events (that can't be perceived from the 
sound track) is provided to the extent possible given the constraints posed 
by the existing audio track (and constraints on freezing the audio/visual 
program to insert additional auditory description).
    * ***Who is supposed to review this? The person who produced the site? 
Some sort of review committee?
    * Where do you put the statement? Is there supposed to be a single 
statement page, or does every page with media have to have a separate 
statement? Won't that add a lot of noise?***
    * captions and Audio descriptions are provided for all live broadcasts 
that are professionally produced.
    * ***Please define "professionally produced". What is the importance of 
that? Wouldn't it make more sense for the professionally produced things to 
have captions at a minimum?***
    * if Web content is an interactive audio-only presentation, the user is 
provided with the ability to view only the captions, the captions with the 
audio, or both together.
    * ***Doesn't "the captions with the audio" mean the same thing as "both 
together"?***



You will have successfully met Checkpoint 1.2 at Level 3 if:

    * a text document (a "script") that includes all audio and visual 
information is provided.
    * ***How is this different from a transcript? This would be much easier 
to meet than the current minimum criteria.***
    * captions and Audio descriptions are provided for all live broadcasts 
which provide the same information.



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Definitions (informative)

A time-dependent presentation is a presentation which
    * is composed of synchronized audio and visual tracks (e.g., a movie), OR
    * requires the user to respond interactively at specific times in the 
presentation.
Media equivalents present essential audio information visually (captions) 
and essential video information auditorily (audio descriptions).
    * captions are text equivalents of auditory information from speech, 
sound effects, and ambient sounds that are synchronized with the multimedia 
presentation.
    * audio descriptions are equivalents of visual information from 
actions, body language, graphics, and scene changes that are voiced (either 
by a human or a speech synthesizer) and synchronized with the multimedia 
presentation.



Benefits (informative)

    * People who are deaf or have a hearing loss can access the auditory 
information through the captions.
    * People who are blind or have low vision as well as those with 
cognitive disabilities who have difficulty interpreting visually what is 
happening benefit from the audio descriptions of the visual information.
People without disabilities also benefit from the media equivalents.
    * People in noisy environments or with muted sound often use captions.
    * Captions are used by many to develop language and reading skills.
    * Audio descriptions also provide visual information for people who are 
temporarily looking away from the video presentation such as when following 
an instructional video and looking at their hands.
    * Captions and text descriptions can also be used to index and search 
media files.
Note: Time-dependent presentations that require dual, simultaneous 
attention with a single sense can present significant barriers to some 
users. Depending on the nature of the of presentation, it may be possible 
to avoid scenarios where, for example, a deaf user would be required to 
watch an action on the screen and read the captions at the same time. 
However, this would not be achievable for live broadcasts (e.g. a football 
game). Where possible, provide content so that it does not require dual, 
simultaneous attention or so that it gives the user the ability to 
effectively control/pause different media signals.


Examples (informative)

    * Example 1: a movie clip with audio description and captions.
    * A clip from a movie is published on a Web site. In the clip, a child 
is trying to lure a puppy to the child's bedroom by laying a trail of 
crumbs. The child mumbles inaudibly to himself as he lays the trail. When 
not watching the video, it is not obvious that he is laying a trail of 
crumbs since all you hear is the mumbling. The audio description that is 
interspersed with the child's mumbling says "Charlie lays a crumb on each 
stair leading to his room." The caption that appears as he mumbles is, 
"[inaudible mumbling]."
    * Example 2: a video clip of a news story.
    * A video clip accompanies a news story about the recent flooding in a 
major city. The reporter describes what is seen, for everyone. No audio 
description is necessary. The captions display what the reporter is saying.
    * Example 3: a silent animation.
    * An animation shows a pantomime climbing a ladder. There is no audio 
track for this animation. No captions or audio description are required. 
Instead, a text equivalent is provided as described in checkpoint 1.1.



Checkpoint 1.3 Make all content and structure available independently of 
presentation.

***Are groupings considered structure? For example, in SAP Web apps, there 
are screen elements called group boxes. A group box is a grouping of other 
elements (such as checkboxes, input fields, etc.) on the screen in a box 
with a title. Would these be considered structure or presentation?***


Success criteria




You will have successfully met Checkpoint 1.3 at the Minimum Level if:

    * any information that is conveyed through presentation formatting is 
also provided in either text or structure.
    * ***What does it mean to convey presentation through structure? Does 
it mean, for example: Use tags for the presentation formatting instead of 
using hard-coded formatting? Does all layout information have to be 
described textually?***
    * the following can be derived programmatically (i.e. through assistive 
technology compatible markup or data model) from the content without 
interpreting presentation.
        * any hierarchical elements and relationships, such as headings, 
paragraphs and lists
        * any non-hierarchical relationships between elements such as 
cross-references and linkages, associations between labels and controls, 
associations between cells and their headers, etc.
        * any emphasis
        * ***"through assistive technology compatible markup": Which 
assistive technology specifically? All of them? Only some of them? They all 
do things differently, so compatibility is an issue. How would you check 
that you meet this criterion?***



You will have successfully met Checkpoint 1.3 at Level 2 if:

    * (presently no additional criteria for this level.)



You will have successfully met Checkpoint 1.3 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Definitions (informative)

Content is the information or meaning and function.

Presentation is the rendering of the content and structure in a form that 
can be sensed by the user.

Structure includes both hierarchical structure of the content and 
non-hierarchical relationships such as cross-references, or the 
correspondence between header and data cells in a table.


Benefits (informative)

    * Separating content and structure from presentation allows Web pages 
to be presented differently to meet the needs and constraints of different 
users without losing any of the information or structure. For example, 
information can be presented via speech or braille (text) that was 
originally intended to be presented visually.



Examples (informative)

    * Example 1: a multi-column document.
    * A document is marked up with headings, paragraphs and other 
structural features. It is presented visually in three columns. The markup 
that creates the columns is separate from the markup that specifies the 
logical structure of the document.
    * Example 2: a scrolling list of stock prices.
    * Current stock quotes are scrolled horizontally across the screen. The 
data are separate from the methods used to scroll the text across the page.
    * Example 3: a 3-dimensional site map.
    * A custom user interface renders 3D visualizations of the pages on a 
site and how they relate to one another from a data source. Any 
hierarchical relationships, groupings, cross-references, etc. would 
originate in the data source so that alternate interfaces could be rendered 
(from the same source) that expose the structure of the site in an 
accessible form. (See also checkpoint 5.4)
    * Example 4: a list that allows users to sort information on a page 
according to preference.
    * A script allows a user to rearrange a categorical listing of music 
files by date, artist, genre, or file size. The script updates both the 
structure and the presentation accordingly when generating alternate views.



Checkpoint 1.4 Ensure that foreground content is easily differentiable from 
background for both auditory and visual presentations.




Success criteria




You will have successfully met Checkpoint 1.4 at the Minimum Level if:

    * no text content is presented over a background picture, color or 
pattern that seriously interferes with readability unless the background 
picture or pattern can be easily removed.
    * prepared audio presentations do not have background sounds that 
seriously interfere with foreground auditory content.
    * ***What does "prepared" mean? Not real-time?
    * How does/do personalization/user settings affect this? If you provide 
personalization, do you meet the requirement, or does the default setting 
in the Web app have to comply?***



You will have successfully met Checkpoint 1.4 at Level 2 if:

    * the site has a statement asserting that pages that might provide a 
problem have been run through a simulator for major types of color 
blindness and are deemed to be still easily readable.
    * ***Which simulator, and how do we use it? We've used one before, and 
it did not recognize the SAP color palette. It would take a lot of work to 
pre-screen for potential "problem screens." This should be a Level 3 
criterion unless sample testing is enough, because otherwise it is a very 
tall order for a Web app.***



You will have successfully met Checkpoint 1.4 at Level 3 if:

    * there are no background pictures or patterns behind foreground content
    * background sounds are at least 20 db lower than foreground content.



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Benefits (informative)

    * Individuals with low vision can easily make out characters in the 
content even if they don't have the wide field of view used by fully 
sighted persons to separate text from background images.
    * Individuals with hearing impairments that limit their ability to hear 
all of the frequencies of speech can make out the words from the sounds 
they can hear because they are not mixed with residual sounds from the music.



Examples (informative)

    * Example 1: a background image on a page.
    * A background image and text are arranged so that there is no image 
behind the text or the image is so faint that the difference between the 
darkest part of the image and the text (which is dark) meets the standard 
foreground/background contrast requirements. The image behind the text also 
does not contain lines that are about the same width as the characters so 
they do not interfere with character recognition.
    * Example 2: background music.
    * There are no sounds or background music playing behind the narration 
or they are ?? db down.



Checkpoint 1.5 Provide information needed for unambiguous decoding of the 
characters and words in the content.




Success criteria




You will have successfully met Checkpoint 1.5 at the Minimum Level if:

    * text in the content is provided in Unicode or sufficient information 
is provided so that it will be automatically mapped back to Unicode.



You will have successfully met Checkpoint 1.5 at Level 2 if:

    * passages or fragments of text occurring within the content that are 
written in a language other than the primary natural language of the 
content as a whole, are identified, including specification of the language 
of the passage or fragment.
    * abbreviations and acronyms are clearly identified where they occur. 
(See also checkpoint 4.3.)
    * ***What does "are clearly identified" mean? Do you mean: Use markup 
to identify that this is an abbreviation or acronym?***
    * symbols such as diacritic marks that are found in standard usage of 
the natural language of the content and necessary for unambiguous 
interpretation of words are present or another standard mechanism for 
disambiguation is provided.



You will have successfully met Checkpoint 1.5 at Level 3 if:

    * the primary natural language of the content is identified at the page 
level.
    * ***Does this mean to use the language tag in HTML, for example?***
The following are additional ideas for enhancing a site along this 
particular dimension:
    * (presently no additional criteria for this level.)
Note: This checkpoint addresses the need for authors to provide sufficient 
information so that text can be identified correctly by technologies used 
to render the text (e.g. voice synthesizers) so that the words can be 
accurately produced and perceived. This checkpoint does not deal with 
providing definitions or expanded text for words, abbreviations, foreign 
phrases etc. These are covered under checkpoint 4.3 since they deal with 
understanding of the content.


Definitions (informative)

***Include a definition of Unicode.***

Natural languages are those used by humans to communicate, including 
spoken, written, and signed languages.


Benefits (informative)

    * Phrases from various languages, acronyms and abbreviations are often 
interspersed in writing. When these phrases are identified, a speech 
synthesizer can voice text with the appropriate accent and pronunciation. 
When they are not identified, the speech synthesizer will use the default 
accent and pronunciation of the language on the rest of the page, which can 
make the phrase unintelligible. Identifying changes in language and marking 
abbreviations and acronyms as such will also allow a tool to ask for 
automatic translations of that content. When editing content, authoring 
tools can switch between appropriate spelling dictionaries.
    * Facilitating unambiguous decoding of characters and words in content 
is also helpful for individuals who are learning to read or learning a 
second language.



Examples (informative)

    * Example 1: a French phrase in an English sentence.
    * In the following sentence, "And with a certain je ne sais quoi, she 
entered both the room, and his life, forever." the French phrase "je ne 
sais quoi" is marked as French. Depending on the markup language, English 
may either be marked as the language for the entire document except where 
specified, or marked at the paragraph level.
    * Example 2: an acronym in a page title.
    * In the following heading, "People of the W3C." the acronym "W3C" is 
marked as an acronym. Because it has been marked appropriately, the user 
agent would be able to speak the letters of the acronym one at a time 
rather than attempting to pronounce it as though it were a word.

----------


Guideline 2 - Operable.
Ensure that the interface elements in the content are operable by any user.

Also essential to accessibility is the ability to be able to operate all of 
the interface elements on the page without requiring the use of specific 
input devices.

This guideline impacts individuals who are blind, individuals who have low 
vision and have trouble with eye-hand coordination input devices, 
individuals with physical disabilities who cannot handle direct pointing 
devices accurately, and individuals with language and learning disabilities 
who would like to use speech input now or in the future.


Checkpoint 2.1 Ensure that all of the functionality of the content is 
operable through character input to the content or user agent.




Success criteria




You will have successfully met Checkpoint 2.1 at the Minimum Level if:

    * content uses only event handlers that are designed to be operable 
through character input.
        * Note: refer to checkpoint 5.3 for information regarding user 
agent support.



You will have successfully met Checkpoint 2.1 at Level 2 if:

    * wherever a choice between event handlers is available and supported, 
the more abstract event is used.
    * ***This item is not clear as currently worded and needs rewording. 
Does it mean to use device-independent event handlers? If so, say that 
instead. Otherwise, clarify. What is a "more abstract event"? "Used" how?***



You will have successfully met Checkpoint 2.1 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Definitions (informative)

Character input is defined as those characters that can be mapped to the 
character set of the W3C Character Model (which is based on Unicode).


Benefits (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 (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.



Checkpoint 2.2 Allow users to control any time limits on their reading, 
interaction or responses unless control is not possible due to the nature 
of real-time events or competition.




Success criteria




You will have successfully met Checkpoint 2.2 at the Minimum Level if:

    * at least one of the following is true for each time limit:
        * the user is allowed to deactivate the time limits,
        * or the user is allowed to adjust the time limit over a wide range 
which is at least 10 times the average user's preference,
        * or the user is warned before time expires and given at least 10 
seconds to extend the time limit,
        * or the time limit is due to a real-time event (e.g. auction) and 
no alternative to the time limit is possible,
        * or the time limit is part of a competitive activity where timing 
is an essential part of the activity (e.g. competitive gaming or time based 
testing).



You will have successfully met Checkpoint 2.2 at Level 2 if:

    * (presently no additional criteria for this level.)



You will have successfully met Checkpoint 2.2 at Level 3 if:

    * activities are designed so that time limits are not an essential part 
of the activity (e.g. competition, testing, etc. are not time based).



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Definitions (informative)

Real-time events are those that are based on the occurrence of events in 
real-time where the events are not under the control of the author.

A competitive activity is an activity where timing is an essential part of 
the design of the activity. Removal of the time element would change the 
performance of the participants. Versions of the activity (e.g. test) that 
have no time basis or time limits might be preferred and may be required 
for some venues but this would require a complete redesign of the activity 
(e.g. test) and may change the character and validation methodology and 
would therefore not fall under these guidelines.


Benefits (informative)

People with reading disabilities, cognitive disabilities, and learning 
disabilities often need longer than most people to read and comprehend 
written text. People with physical disabilities might not be able to move 
quickly or accurately enough to interact with moving objects.

Content that is updated often might not be processed and read in time or in 
the proper order by an assistive technology or voice browser.


Examples (informative)

Examples of content that requires a response within a timed interval:
    * automatic refresh,
    * redirection,
    * blinking or scrolling text
    * dialog that disappears after a short period
    * shutdown or deactivation of page if activity is not received in a set 
amount of time
    * Example 1: blinking text.
    * Client-side scripting is used to create blinking text. The user can 
deactivate the use of scripting in his or her browser or override the use 
of scripts with a user style sheet.
    * Example 2: a news site that is updated regularly.
    * A news site causes its front page to be updated every 1/2 hour. The 
front page contains minimal text and primarily consists of links to 
content. A user who does not wish the page to update selects a checkbox. 
The checkbox is in the "user preferences" portion of the site which is one 
of the first links on each page.



Checkpoint 2.3 Avoid causing the screen to flicker.




Success criteria




You will have successfully met Checkpoint 2.3 at the Minimum Level if:

    * At least one of the following is true:
        * content was not designed to flicker (or flash) in the range of 3 
to 49 Hz.
        * ***Could you include a visual example? ***
        * Reviewer's Note: We would like to include a criteria here which 
would state that a test that was conducted and the pages passed. No test or 
tool exists yet though. We're looking into how such a test and/or tool 
might be designed.
        * if flicker is unavoidable, the user is warned of the flicker 
before they go to the page, and as close a version of the content as is 
possible without flicker is provided.



You will have successfully met Checkpoint 2.3 at Level 2 if:

    * the site has a statement asserting that animation or other content 
does not visibly or purposely flicker between 3 and 49 Hz.
    * the site has a statement asserting that pages that might provide a 
problem has been tested [using XYZ tool], only pages with unavoidable 
flicker remain and appropriate warnings along with a close alternative 
presentation has been provided for these pages.
    * (tougher test - that would make pages pass with even slower equip. 
Equip might be old or just slow for other reasons)



You will have successfully met Checkpoint 2.3 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)
Reviewer's Note: Trace is currently in the process of exploring an 
automated flicker testing tool.


Benefits (informative)

    * Individuals with photosensitive epilepsy can have seizures triggered 
by flickering or flashing in the 3 to 49 flashes per second (Hertz) range 
with a peak sensitivity at 20 flashes per second.
    * Individuals with distractibility problems may not be able to focus on 
page content with flicker occurring in the same visual field.

----------


Guideline 3 - Navigable.
Facilitate content orientation and navigation

Key to effective use of Web content is the ability to obtain and keep one's 
orientation within a document and/or Web site, and the ability to 
efficiently move about in the site or document.


Checkpoint 3.1 Provide structure within content.

***How does this checkpoint apply to screens in a Web app? Something 
analagous needs to be added for application structure. Would menus satisfy 
the structure checkpoint?

Also, this checkpoint seems to be about usability, not accessibility. 
Imposing structure through these guidelines regulates usability. The point 
we feel is most valid here is Level 3, #1, which should be the minimum 
requirement.***


Success criteria




You will have successfully met Checkpoint 3.1at the Minimum Level if:

    * the following minimum structure elements are present.
        * titles on major sections of long documents
        * paragraphs



You will have successfully met Checkpoint 3.1 at Level 2 if:

    * the site has a statement asserting that author(s) or others have 
reviewed content and added as much structure as they felt was appropriate 
or possible.



You will have successfully met Checkpoint 3.1 at Level 3 if:

    * 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.



The following are additional ideas for enhancing a site along this 
particular dimension

Note: Because the form and origin of content (including letters, poetry, 
historical documents, etc.) varies so greatly, specific criteria for the 
type and amount of structure to be put into content can not be 
standardized. Objective success criteria cannot therefore be formulated 
that would apply across media and documents. Advisory recommendations are, 
however, listed below to provide guidance in adding key structural elements 
into the content. See also the techniques documents for the different 
technologies.
    * break up text into logical paragraphs.
    * provide hierarchical sections and titles, particularly for longer 
documents
    * reveal 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.
    * divide very large works into sections and or chapters with logical 
labels.
    * others?



Definitions (informative)

The 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. All of these divisions 
help the reader anticipate changes in context.
    * 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."



Benefits (informative)

***All of these benefits appear to be usability benefits, not accessibility 
benefits.***

When the logical structure is provided in markup or a data model,
    * Users with physical disabilities can use structure to more easily 
jump between paragraphs, chapters, sections etc.
    * Users with cognitive disabilities can use structure (chapter titles, 
headers, etc.) to provide more context for the text that follows them. They 
also provide warning of a change in context and reorient the user to the 
new focus.
    * Users with blindness or low vision can jump from header to header to 
get an overview or to more quickly "skim" to the section they are 
interested in.
    * Readers with low vision can sometimes (depending on display 
technology) change how chapter titles and headers are displayed to make 
them more visible -and easier to use when skimming the document.
    * 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.



Examples (informative)

    * Example 1: a physics dissertation.
    * A dissertation contains well-defined sections such as "Abstract," 
"Table of Contents," "Chapter 1," etc. The pieces in each section 
(paragraphs, subheadings, quotes) are denoted with structural markup.
    * Example 2: a scalable image of a bicycle.
    * Lines and a circle (spokes and rim) are grouped into a "wheel." Lines 
in a triangle that attach to each wheel are grouped into a "frame."
    * ***This implies images are supposed to have structure too, like 
documents. Why would structure be mandatory here? If the author is not 
trying to provide information about the structure of the bike, but rather 
display the bike as a whole, how is that a problem? Also, it would be 
really helpful here to see a visual example of what the example would look 
like.***
    * Example 3: user interface.
    * User interface controls are divided into organized groups.



Checkpoint 3.2 Emphasize structure through presentation(s), positioning, 
and labels.

***How does this checkpoint apply to Web app screens?***


Success criteria




You will have successfully met Checkpoint 3.2 at the Minimum Level if:

    * the structural elements present have a different visual appearance or 
auditory characteristic than the other structural elements.
    * ***What is meant by "the other structural elements"?***



You will have successfully met Checkpoint 3.2 at Level 2 if:

    * the structural emphases are chosen to be distinct for different major 
display ***or audio?*** types (e.g. black and white, small display, mono 
audio playback).
    * ***What does it mean for the structural emphases to be distinct? 
Also, what are the major display types we would have to do this for? We 
need a list.***



You will have successfully met Checkpoint 3.2 at Level 3 if:

    * content is constructed such that users can control the presentation 
of the structural elements.
    * ***Would this replace the minimum criteria, or would it be in 
addition to the minimum?***
    * alternate presentation formats are available to vary the emphasis of 
the structure.



The following are additional ideas for enhancing a site along this 
particular dimension:

Note: Because the form and origin (including letters, art, historical 
documents, etc) of content varies so greatly, specific criteria for the 
type and amount of emphasis to be provided can not be standardized. 
Objective success criteria cannot therefore be formulated that would apply 
across media and documents. Advisory recommendations are however listed 
below to provide guidance in emphasizing the structure of content. See also 
the techniques documents for the different technologies.
    * for visual presentations, use font variations, styles, size and white 
space to emphasize structure.
    * use color and graphics to emphasize structure.
    * for auditory presentations, use different voice characteristics 
and/sounds 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, use additional graphics, colors, sounds, and other aspects of 
presentation to emphasize the structure.
    * ***What does "not salient enough" mean? How do you measure that?***
    * provide a table of contents or navigation map of the document.
Note: Ensure that the structural and semantic distinctions are provided in 
the markup or data model. Refer to checkpoint 2.2.


Benefits (informative)

Presentation that emphasizes structure:
    * enables users with cognitive and visual disabilities to orient 
themselves within the content,
    * enables all users to move quickly through the content and notice 
major content divisions
    * enables all users, but particularly users with visual or cognitive 
disabilities to focus on important content,
    * enables all users, but particularly users with visual or cognitive 
disabilities to separate the different types of content.



Examples (informative)

    * Example 1: documentation for a product.
    * Identifying chapters in the structure of a book is appropriate and 
accepted use of labeling the structure. Within the chapters, headings 
identify (label) changes in context and highlight ideas contained in the 
following text. Subtle differences between the appearance of the chapter 
title and the section headings helps the user understand the hierarchy and 
relationship between the title and headings. The only difference might be 
font size and margin indentation when presented visually, and spoken in a 
difference voice or preceded by a sound when presented auditorily.
    * Example 2: a data table.
    * Groups of rows or columns are labeled with headers.
    * Example 3: an audio file.
    * An audio file of a document uses a different, more formal voice to 
read titles and headers so the listener can easily identify the words as a 
title and not part of the running text.



Checkpoint 3.3 Provide multiple methods to explore sites that are more than 
two layers deep.

***What are the layers in a Web application? What would constitute a layer 
in a Web-based wizard? Is a layer horizontal or vertical in the structure?
This checkpoint does not seem to apply very well to Web apps. If there is a 
Submit button, for example, why should it be duplicated with a navigation link?
What about Web sites where content is displayed dynamically based on the 
user's profile, etc.? A site map would be difficult to make.
This seems to us to be a usability checkpoint, not accessibility. The 
benefits listed all point to usability.***


Success criteria




You will have successfully met Checkpoint 3.3 at the Minimum Level if:

    * sites that have more than two layers have at least one other method 
for exploration besides using the links on the home page. (A home page and 
one layer of pages linked off of it would be two layers)
    * a link to the alternate exploration method(s) is provided on the home 
page.



You will have successfully met Checkpoint 3.3 at Level 2 if:

    * sites that have documents that span multiple files either provide the 
documents as a single file or provide a search function which would allow 
the user to search for a word across only the files that make up that 
document.



You will have successfully met Checkpoint 3.3 at Level 3 if:

    * large documents (greater than 50,000 words) include multiple 
mechanisms for navigation such as a hyperlinked table of contents, internal 
hyperlinks, an ability to collapse by headers, etc.



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Definitions (informative)

A site navigation mechanism is a mechanism for easily orienting and moving 
about within the site. Site navigation mechanisms include but are not 
limited to:
    * A Home page with hyperlinks on it and subsequent pages that link to 
the other pages at the site.
    * site map(s)
    * search engine(s)
    * expanding outline(s)
    * dynamic fisheye views showing all linked pages or topics related to 
any page.
    * 3-D virtual representations of site content



Benefits (informative)

    * Providing different navigation mechanisms can provide a better match 
between different people's skills, background knowledge, visual vs. text 
orientation, and the type of information they are seeking at the moment.
    * Individuals with cognitive disabilities may find it easier to ask for 
what they want than to deduce its location from categorical choices.
    * Individuals with low vision or blindness may find search techniques 
that fetch everything that relates to a topic of interest to be easier than 
techniques that require them to scan lists or pages for the items.



Checkpoint 3.4 Use consistent but not necessarily identical presentation.

***Again, a usability issue, not an accessibility issue.***


Success criteria




You will have successfully met Checkpoint 3.4 at the Minimum Level if:

    * key orientation and navigational elements are generally found in one 
or two locations or their locations are otherwise predictable.
    * ***What is considered "key"? This is subjective. Key elements need to 
be defined. What does "are otherwise predictable" mean? Can you give an 
example? Some SAP Web app screens have tabstrips and trees that include 
links. Would these have to comply with this guideline?***



You will have successfully met Checkpoint 3.4 at Level 2 if:

    * the site has a statement asserting that author(s) or others have 
reviewed the content and concluded that key orientation and navigational 
elements are generally found in one or two locations or their locations are 
otherwise predictable.



You will have successfully met Checkpoint 3.4 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * place navigation bars in a consistent location whenever possible
    * similar layout for user interface components should be used for 
sections or whole site,
    * ***Why "or"? Should specify which: the whole site or a section of a 
site.***
    * similar user interface components should be labeled with similar 
terminology
    * ***Similar user interface components within what scope? In a Web app, 
would this be components within a single transaction or function, or would 
it be components within the whole application? What about a suite of 
applications?***
    * use headers consistently
    * ***What exactly is meant by headers here?***
    * use templates for consistent presentation of sections or whole site
    * pages with similar function should have similar appearance and layout



Definitions (informative)

Presentation includes, but is not limited to:
    * position,
    * font, font size,
    * color
    * voice and voice characteristics
    * sounds
    * white space



Benefits (informative)

    * Consistency helps users predict where to find information on each 
page of your site. It also helps users determine the relationships between 
items in the content. This understanding of the structure helps users 
navigate and orient themselves.
    * ***Usability benefit, not accessibility. Being able to find something 
is accessibility. Being able to predict where it can be found is usability.***
    * Differences in presentation help users determine that they have 
succeeded in loading a new page. Pages that are clearly different also 
makes it easier for users to tell where they are and to remember where 
information is located.
    * ***One could read this point to mean that every page should be 
different. Not sure that makes as much sense in a Web app, where a lot of 
the areas on the screen, like navigation, are consistent from screen to 
screen.***



Checkpoint 3.5 Provide consistent and predictable responses to user actions.

***How far in advance does the warning need to come? Does telling the user 
during training about what certain responses will be cover this checkpoint? 
What about telling them in the documentation? If something in a Web app is 
unpredictable, it's usually unpredictable for non-disabled as well as 
disabled users. Furthermore, what is the true usability goal here: 
usability or learnability?

What should the predictability be based on? Industry standards? The user's 
learned expectations within that Web app? For example, in some SAP Web 
apps, the user can tab to text. This may not be expected by new SAP users 
who use screen readers and are used to not being able to tab to anything 
but interactive elements, but new users have provided us with positive 
feedback on this feature, as it ensures they receive information about 
everything on the screen.***


Success criteria




You will have successfully met Checkpoint 3.5 at the Minimum Level if:

    * where inconsistent or unpredictable responses are essential to the 
function of the content (e.g. mystery games, adventure games, tests, etc.) 
the user is warned in advance of encountering them.
    * ***Could you include a more pertinent example too, like a Web app or 
an e-commerce site or something, not just mystery games or tests?***
    * wherever there are extreme changes in context, one of the following 
is true:
        * an easy to find setting, that persists for the site visit, is 
provided for the user to deactivate processes or features that cause 
extreme changes in context or
        * extreme changes in context are identified before they occur so 
the user can determine if they wish to proceed or so they can be prepared 
for the change



You will have successfully met Checkpoint 3.5 at Level 2 if:

    * the site has a statement asserting that authors or others have 
reviewed the content and found that where inconsistent or unpredictable 
responses are essential to the function of the content (e.g. mystery games, 
adventure games, tests, etc.) the user is warned in advance of encountering 
them.



You will have successfully met Checkpoint 3.5 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * 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,
    * ***What does this mean for companies like ours? That we cannot do any 
new or innovative design?***
    * 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. ***Would providing this information during training satisfy 
this point?***

    * ***We agree that basic browser navigation behavior should be 
followed, but we don't agree that it needs to be regulated through 
guidelines like these.***



Definitions (informative)

Mechanisms that cause extreme changes in context include:
    * opening a new browser window unexpectedly and without any nonvisual 
cue (back button suddenly appears nonfunctional)
    * in an auditory presentation, the speaker changes with no visual cue 
and no notation in captions.
    * captions that do not identify a change in speaker
Common user actions include:
    * mouse movements
    * key activation
    * link selection
    * use of browser navigation buttons (e.g. back and forward)
    * opening new browser windows
Common responses to user actions include:
    * loading a new page
    * exposing/concealing content based on mouse position or keyboard focus
    * displaying the contents of a menu (auditorally or visually)
    * displaying pop-up menus or windows
    * submitting a form
It is important that responses to user actions be predictable and sensible 
to the end user and that interactions are consistent, both throughout the 
site and with commonly used interaction metaphors used throughout the Web.


Benefits (informative)

    * Individuals who are unable to detect extreme changes in context or 
may not realize that the context has changed are less likely to become 
disoriented while navigating a site. This applies to people in the 
following ways:
        * Individuals who are blind or have low vision may have difficulty 
knowing when a visual context change, such as a new window popping up, has 
occurred. In this case, warning users of context changes in advance 
minimizes confusion when the user discovers that the back button no longer 
behaves as expected.
        * Using captions to note changes in speaker is beneficial for 
individuals who are deaf or hard of hearing and who may be unable to 
discern changes in speaker for audio-only presentations.
    * Some individuals with low vision, with dyslexia and who have 
difficulty interpreting visual cues may benefit from additional cues in 
order to detect extreme changes in context.
Note: Providing consistent and predictable responses to user actions is 
important feedback for the user. This lets them know that your site is 
working properly and encourages them to continue interacting with the 
content. When the user receives an unexpected response, they might conclude 
that something is wrong or broken. Some people might get so confused they 
will not be able to use your site.


Examples (informative)

    * Example 1: a form to deactivate pop-up windows.
    * A checkbox is provided on a page of links to let the user select 
whether they want the resultant pages to appear in new windows or not.
    * Example 2: a warning given before a pop-up window.
    * At the end of a news story, several links are provided for more 
information. At the beginning of each link is an icon of an arrow with the 
text equivalent, "Link will open in new window."
    * Example 3: frames that do not track history making the back button 
behave unexpectedly.
    * Example 4: forms. ***Explanation missing here.***
Reviewer's Note: Some of these examples are very brief. Should they be 
expanded and clarified with further details?


Checkpoint 3.6 Provide methods to minimize error and provide graceful recovery.

***We're not sure we see the link to accessibility here. Again, it seems to 
be more of a usability issue.***


Success criteria




You will have successfully met Checkpoint 3.6 at the Minimum Level if:

    * if an error is detected, feedback is provided to the user identifying 
the error.
    * ***This only meets one of the checkpoint's goals: provide graceful 
recovery. What about minimizing errors?***



You will have successfully met Checkpoint 3.6 at Level 2 if:

    * the site has a statement asserting that the content has been reviewed 
and is believed to have incorporated error prevention and recovery methods 
that author(s) or others felt were possible and appropriate.



You will have successfully met Checkpoint 3.6 at Level 3 if:

    * where possible, the user is allowed to select from a list of options 
as well as to generate input text directly
    * ***Is this intended to say that if it's possible to allow the user to 
select from a list, that should be done AND users should be allowed to 
input text directly? Or is it intended to say that if it's possible to 
allow the user to select from a list, that should be provided INSTEAD of 
direct text input? We feel it should be the latter, not the former.***
    * 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.
    * ***Our Web apps have input fields and text boxes everywhere, on 
practically every screen. This sort of spell checking would negatively 
affect system performance. Also, our apps support many different languages, 
so we would require spell checkers for each language. It's not clear how 
this is an accessibility issue.***
    * where consequences are significant and time-response is not 
important, one of the following is true
        * actions are reversible where possible
        * where not reversible, actions are checked for errors in advance.
        * where not reversible, and not checkable, a confirmation is asked 
before acceptance



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Benefits (informative)

    * Individuals with writing disabilities and people with dyslexia often 
have difficulty writing text in forms or other places that need text input.
    * Individuals with speech disabilities might not be recognized properly 
in voice input applications.



Examples (informative)

    * Example 1: a search engine.
    * A search engine is provided with a variety of search options for 
different skill levels and preferences. It includes a spell checker and 
offers "best guess" alternatives, query-by-example searches, and similarity 
searches.

----------


Guideline 4 - Understandable.
Make it as easy as possible to understand the content and controls.

To help people understand the information you are presenting, consider the 
various ways that people learn. Keep in mind the variety of backgrounds and 
experiences people will bring to your site. Using language, illustrations, 
and concepts that they are likely to know, highlighting the differences and 
similarities between concepts, and providing explanations for unusual terms 
can all facilitate understanding.

***The complexity of some enterprise Web apps presupposes a certain level 
of cognitive ability. Furthermore, to make Web apps understandable for 
users, companies train their users. ***


Checkpoint 4.1 Write as clearly and simply as is [appropriate / possible] 
for the purpose of the content.

***What cognitive disabilities are covered here? What is the goal for each 
disability? While our Web apps could be used by people with some cognitive 
disabilities, they could not be used by people with all types of cognitive 
disabilities.***

Reviewer's Note: This item is under discussion. There is consensus for the 
existence of the checkpoint but not for the form of the success criteria. 
We do not therefore have something for the draft at this time. There is a 
list below of items that are being explored for inclusion either as success 
criteria or as Advisory Recommendations. We are also compiling a longer 
list (approx 50 items) of different ideas that relate to this checkpoint.

This checkpoint is very difficult and the group is wrestling with a number 
of problems. Among them:
    * It is very difficult to determine what makes writing clear and simple 
for all topics.
    * Some content is derived from other sources and is copyrighted so it 
cannot be altered.
    * Some materials or topics cannot be communicated accurately in simple 
language.
    * There are some cases where the form is specific to the intent, 
(poetry, exposition )
    * Since some people can not understand the content no matter how simply 
it is written, it is not possible to make any content accessible to 
everyone. Therefore, we are having difficulty finding specific objective 
criteria that could be applied across all types of content and sites.
Comments, suggestions and contributions to the discussion and work on this 
topic are also solicited. Refer to the issues list for more information.


Success criteria




You will have successfully met Checkpoint 4.1 at the Minimum Level if:

    * (still under construction.)



You will have successfully met Checkpoint 4.1 at Level 2 if:

    * (still under construction.)



You will have successfully met Checkpoint 4.1 at Level 3 if:

    * (still under construction.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (still under construction.)



Partial list of items being explored for inclusion as success criteria or 
advisory recommendations

    * content under site control is written as clearly and simply as the 
author feels [appropriate / possible] for the purpose of the content.
    * a statement is provided on the site which asserts that those 
responsible for the site have reviewed the materials on the site and the 
content under their control is written as clearly and simply as they feel 
is [appropriate / possible] for the purpose of the content.
    * summaries and/or simpler forms are provided for key pages or sections 
of the site. ***What should be considered "key" pages or sections? Who 
decides that?***
    * provide an outline or a summary for your document.
    * ***Points 3 and 4 would be an additional burden for us to implement 
in our Web apps. Plus, summaries would cause maintenance headaches.***
    * break up long paragraphs into shorter ones, with one idea per paragraph.
    * break up long sentences into shorter ones.
    * ***Wouldn't 5 and 6 be considered issues of style? How can you 
regulate style?***
    * provide accurate unique page titles.
    * ***Does this mean, for example, use the HTML title tag, or are we 
talking about the title in the content section of a page?***
    * ensure that headings and link text are unique and that they make 
sense when read out of context.
    * ***This would require a lot of effort to implement in Web apps like 
ours. We might have three group boxes on a screen, each of which has its 
own Submit button specific to that group box. But we would still use the 
text "Submit" for each button. If this is made into a criteria, it should 
be a Level 3.***
    * provide definitions for any jargon or specialized terminology used in 
your document.
    * ***Where would we put these in a Web app? Would a glossary of terms 
be good enough? SAP has a lot of specialized terminology, and each industry 
that our applications address has a lot of its own specialized terminology 
as well.***
    * provide explanations of figurative, metaphorical, or idiomatic uses 
of language (for example, 'haven't seen you in a coons age' or 'the sight 
tore my heart out').
    * ***If you have to explain such language usage, why would you use it 
in the first place? Again, this is a style issue that we don't feel should 
be regulated.***
    * language should be used that your intended audience ought to be 
familiar with.
    * ***This one would be better to use than Point 10 or Point 12.***
    * when introducing new concepts or terms, they should be defined or 
annotated in language that the audience is expected to be familiar with, or 
definitions or explanations should be linked to that might be easier to 
understand.



Benefits (informative)

    * All users, especially those with cognitive, learning, and/or reading 
disabilities benefit from the use of clear and simple writing. This should 
not discourage you from expressing complex or technical ideas.
    * Using clear and simple language also benefits people whose first 
language differs from your own, including those people who communicate 
primarily in sign language.



Checkpoint 4.2 Supplement text with non-text content.




Success criteria




You will have successfully met Checkpoint 4.2 at the Minimum Level if:

    * authors have included non-text content to supplement text for key 
pages or sections of the site where they felt it was appropriate.
    * ***Deciding whether it is "appropriate" is very subjective. How would 
you measure whether this checkpoint had been met? What are "key" pages or 
sections, and who defines that?***



You will have successfully met Checkpoint 4.2 at Level 2 if:

    * there is a statement on the site asserting that the materials have 
been reviewed and that text has been supplemented with non-text content to 
the extent deemed appropriate by the author.
    * ***It's not clear what the difference is between this level and Level 
3. Please clarify.***



You will have successfully met Checkpoint 4.2 at Level 3 if:

    * there is a statement on the site asserting that non-text content has 
been added 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.



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)
Note: Supplementing text with non-text (e.g. graphics, sound, smell, etc) 
is useful for all users. However there are no clear guidelines as it 
relates to disability. Specific objective criteria that could be applied 
across all types of content are therefore not possible. Advisory 
recommendations are, however, listed below to provide guidance in this 
area. See also the techniques documents for the different technologies.

Reviewer's Note: Do we have any items to add here or do we just include 
examples below?


Definitions (informative)

Non-text content - includes images, text in raster images, image map 
regions, animations (e.g., animated GIFs), applets and programmatic 
objects, ASCII art, scripts, images used as list bullets, spacers, 
graphical buttons, sounds (played with or without user interaction), 
stand-alone audio files, audio tracks of video, and video.

Reviewer's Note: Is this definition adequate?


Benefits (informative)

***These benefits really focus on Web sites. What about Web apps?***
    * Sounds, graphics, videos and animations can help make concepts 
presented in a Web site easier to understand, especially for people with 
cognitive, reading, or learning disabilities or those who are unfamiliar 
with the language of the text of the site.
Note: Designers need to be cautious in deciding when to use illustrations. 
Reading a picture is probably a learned activity that is easier for some 
than others. Some users skip the pictures; others read only the pictures. 
Designers must also recognize that visual conventions are not universal and 
that individuals develop their own mental schema and expectations in 
interpreting visual information.

***This note is asking a lot of designers. It essentially asks them to know 
about all different kinds of cognitive disabilities.***


Examples (informative)

    * Example 1: a description of a process.
    * A page describes how to learn to play soccer. Each step in learning 
the fundamentals of the game is illustrated with a photograph of a player 
doing what is described in the text.
    * Example 2: a concrete concept.
    * The primary concept on a page is concrete. It is discussing Mt. 
Pinatubo. It includes both a description of the 1991 eruption as well as 
photos of the eruption and the aftermath. It links to another site that 
contains video and another site that contains a 3D simulation of what 
happened underneath the crust and within the volcano during the eruption.
    * Example 3: child's report of school trip.
    * A child went with her school on a trip to a bicycle manufacturing 
plant. She wrote a report for her family and friends to post to the Web. In 
the report, she includes the company logo as well as a picture of a bicycle 
on the assembly line. She links to the company Web site for more 
information. She includes photos she took of the plant.
    * Example 4: stock trading data.
    * A news site is comparing the performance of the economy from 3rd 
quarter of this year with 3rd quarter from the last 3 years. They compare 
prices of the most popular stocks. They present the data in a bar graph 
with a link to the raw data they used to create the bar graph.
    * Example 5: history of music.
    * A grandfather's hobby is listening to and playing music. He creates a 
Web site that includes examples of many different types of music and 
musical instruments. When describing specific types of music, he links to a 
short sound clip.



Checkpoint 4.3 Annotate complex, abbreviated, or unfamiliar information 
with summaries and definitions.




Success criteria




You will have successfully met Checkpoint 4.3 at the Minimum Level if:

    * acronyms and abbreviations are defined the first time they appear.
    * ***The first time they appear on a page? On the site (or Web app)? 
How can you know where the user has started, in order to determine whether 
this is the first time they are encountering the acronym or abbreviation? 
It might require redesigning screens, because of the limitations on screen 
space. Particularly in Web apps like ours, meeting this checkpoint would be 
very resource-consuming.***



You will have successfully met Checkpoint 4.3 at Level 2 if:

    * there is a statement on the site which asserts that authors or others 
have reviewed the content and provided annotations for information where 
they felt is appropriate



You will have successfully met Checkpoint 4.3 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * 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.
    * ***We did not understand this point. Could you give an example?***
    * if contracted forms of words are used such that they are ambiguous, 
provide semantic markup to make words unique and interpretable.
    * ***Not sure what this point means. What is "semantic markup"?***



Definitions (informative)

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.

Examples of complex information:
    * data tables,
    * concepts that are esoteric or difficult to understand,
    * content that involves several layers.
Content might be unfamiliar if you are using terms specific to a particular 
community. For example, many of the terms used in this document are 
specific to the disability community.


Benefits (informative)

    * Summarizing information that is difficult to understand helps people 
who do not read well.
    * Providing a summary of the visual cues that show relationships 
between complex information helps people who do not use visual cues or who 
have difficulty using visual cues. For example, people who are completely 
blind do not use any visual cues, while people with dyslexia or with low 
vision might have difficulty interpreting visual cues.
    * Defining key terms and specialized language will help people who are 
not familiar with the topic.
    * 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.

----------


Guideline 5 - Robust.
Use Web technologies that maximize the ability of the content to work with 
current and future accessibility technologies and user agents.




Checkpoint 5.1 Use technologies according to specification.




Success criteria




You will have successfully met Checkpoint 5.1 at the Minimum Level if:

    * for markup, except where the site has documented that a specification 
was violated for backward compatibility, the markup has passed validity 
tests of the language (whether it be conforming to a schema, Document Type 
Definition (DTD), or other tests described in the specification), 
structural elements and attributes are used as defined in the 
specification, accessibility features are used, and deprecated features are 
avoided.
    * for Application Programming Interfaces (API's), programming standards 
for the language are followed.
    * accessibility features and API's are used when available.



You will have successfully met Checkpoint 5.1 at Level 2 if:

    * for markup, the markup has passed validity tests of the language 
(whether it be conforming to a schema, DTD, or other tests described in the 
specification), structural elements and attributes are used as defined in 
the specification, accessibility features are used, and deprecated features 
are avoided.



You will have successfully met Checkpoint 5.1 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)
Reviewer's Note: Are protocols relevant to this checkpoint? If so, why, and 
should we require that they be used according to specification? Obviously 
there are interoperability advantages in doing so, but is this pertinent to 
accessibility?


Benefits (informative)

    * When languages, API's, and protocols are used according to 
specification, tools that use the results will be able to do so as intended 
and expected.



Examples (informative)

    * Example 1: structural elements.
    * Throughout a Web site, structural elements are not used for purposes 
of presentation. Likewise, presentational elements are not used for 
purposes of structure.
    * Example 2: accessible API's.
    * A Java program uses the accessibility API defined by the language. 
Refer to the <http://www-3.ibm.com/able/snsjavag.html>IBM Guidelines for 
Writing Accessible Applications Using 100% Pure Java.



Checkpoint 5.2 Design for backward compatibility.

***This point seems focused only on the general public user community. But 
what about the user community for certain products? Shouldn't a company 
like ours be allowed to decide ourselves if we want our products to be 
backwards compatible? If backwards compatibility becomes regulated, it 
would limit companies' ability to sell upgrades to existing customers.***


Success criteria




You will have successfully met Checkpoint 5.2 at the Minimum Level if:

    * baseline user agent requirements have been determined and are 
documented in metadata and / or a policy statement on the site.
        * Note: When determining your baseline user agent requirements, 
consider that assistive hardware and software is often slow to adapt to 
technological advances, and the availability of assistive technology varies 
across natural languages. Verify that assistive technology compatible with 
the technologies you choose is available in the natural language(s) of your 
content.
        * ***How far backwards-compatible is far enough? Who determines 
that? How do you measure that? Should you force people not to use Flash at 
all, for example, even if they provide an accessible alternative?***
    * the content is still usable when features above the baseline (for 
example, scripting and stylesheets) are turned off or not supported.



You will have successfully met Checkpoint 5.2 at Level 2 if:

    * (presently no additional criteria for this level.)



You will have successfully met Checkpoint 5.2 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Benefits (informative)

Benefits of determining and documenting baseline user agent requirements:
    * Individuals can identify (either through site documentation or 
automatically through metadata) whether or not they are likely to be able 
to use a site. In conjunction with a search engine or a proxy server, this 
could be used to automatically filter out sites a user can not access or to 
automatically filter to the top sites that would be most usable.
    * Requiring sites to document their baseline will cause them to 
evaluate assumptions about user agents and will minimize the number of 
sites that are inadvertently inaccessible because they are unaware of 
backward compatibility issues.
Benefits of designing for backward compatibility:
    * Individuals who must use alternative browsing technologies and 
devices will be able to access the content.
    * Individuals who can not afford or otherwise do not have access to 
newer technologies also benefit from backward compatibility in that they 
will not need to purchase upgrades or equipment as often.



Examples (informative)

    * Example 1: an online store.
    * By documenting minimum user agent requirements, the store makes it 
possible for people using particular technologies to determine if they are 
going to have trouble using the store or its checkout mechanism without 
having to go through the entire process of shopping and checkout only to 
find out that they are unable to complete their transaction at the end. 
They can, therefore, shop at stores they can be successful at.
    * Example 2: an Intranet site.
    * A large company was concerned about the ability to address 
individuals at many diverse sites that have different technology bases. 
They have, therefore, created two versions of their content and documented 
the requirements for each, making it easy for individual sites to determine 
which version would work for their technologies.



Checkpoint 5.3 Choose technologies that are designed to support accessibility.

***The baseline AT needs to be defined. Otherwise it's too difficult to 
figure out which AT to support.***


Success criteria




You will have successfully met Checkpoint 5.3 at the Minimum Level if:

    * the technology or combination of technologies chosen:
        * support device independence
        * include accessibility features
        * have publicly documented interfaces for interoperability
        * ***Not sure what this means. What are publicly documented 
interfaces?***
        * make use of operating system accessibility features (either 
directly or via the user agent) supported by assistive technologies in the 
natural language(s) of the content
        * are implemented in user agents and/or proxies in the natural 
language(s) of the content
        * ***Not sure what this means. Please clarify.***



You will have successfully met Checkpoint 5.3 at Level 2 if:

    * (presently no additional criteria for this level.)



You will have successfully met Checkpoint 5.3 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Benefits (informative)

    * Authors who utilize technologies designed to support accessibility will:
        * encounter fewer challenges when implementing these guidelines
        * avoid the need to create custom solutions and workarounds to 
address accessibility concerns
        * avoid the need to provide accessible alternate versions for 
content rendered in a technology that does not fully address these guidelines



Checkpoint 5.4 Ensure that user interfaces are accessible or provide an 
accessible alternative.




Success criteria




You will have successfully met Checkpoint 5.4 at the Minimum Level if:

    * any applications with custom user interfaces conform to at least 
Level A of the <http://www.w3.org/TR/UAAG10/>User Agent Accessibility 
Guidelines 1.0. If the application cannot be made accessible, an 
alternative, accessible solution is provided.
    * ***This point needs to be clearer. We cannot tell if we would need to 
follow these other guidelines. If a Web app runs in a standard browser, 
does the interface still have to conform to the other guidelines? What is 
considered an accessible alternative? A text-only site? What would be an 
accessible alternative for a Web app page?***



You will have successfully met Checkpoint 5.4 at Level 2 if:

    * the interface has been tested using a variety of assistive 
technologies and preferably real people with disabilities who use assistive 
technologies to determine that assistive technologies can access all 
information on the page or hidden within the page. ***What does "or hidden 
within the page" mean?
    * Variety of assistive technologies" needs to be defined. Otherwise 
it's too vague. Is it enough, for example, to target JAWS and MAGic?***
    * ***About the Reviewer's Note: Not sure how it would be possible to 
comply with the checkpoint without carrying out tests. The text 
specifically says "the interface has been tested." Please clarify.***
    * Reviewer's Note: It would be possible to comply with the checkpoint 
without carrying out tests (either with users or with assistive 
technologies). Conversely, it is possible to conduct tests, but still fail 
to meet the checkpoint (with respect to assistive technologies that were 
not tested, for example). Should this success criterion be deleted?
    * device-independent access to functionality is provided
    * accessibility conventions of the markup or programming language 
(API's or specific markup) are used



You will have successfully met Checkpoint 5.4 at Level 3 if:

    * (presently no additional criteria for this level.)



The following are additional ideas for enhancing a site along this 
particular dimension:

    * (presently no additional criteria for this level.)



Benefits (informative)

    * Individuals who rely on assistive technologies to access the Web will 
be able interact with the content.
    * Individuals who access the Web with older technologies or alternative 
browsing devices such as PDAs and cell phones also benefit from the 
inclusion of accessible alternatives to custom user interfaces.

----------


Appendix A: Glossary

Reviewer's Note: Should we include only the definitions of terms appearing 
in the guidelines or is there some subset of key terms from the glossary 
that should also be included? We also need to make sure that the 
<http://www.w3.org/WAI/GL/Glossary/>glossary definitions are the same as 
the definitions which appear in the guidelines themselves. For now, a 
simple list of the terms that are defined in this document are included 
below. Definitions for each term will be included at a later date.
    * text equivalent
    * Non-text content
    * time-dependent presentation
    * Media equivalents
    * captions
    * audio descriptions
    * Content
    * Presentation
    * Structure
    * Character input
    * Real-time events
    * competitive activity
    * structure
    * site navigation mechanism
    * Presentation
    * Mechanisms that cause extreme changes in context
    * Non-text content
    * complex
    * unfamiliar



Appendix B: Contributors

<http://www.w3.org/WAI/GL/participants.html>Participants in the WCAG 
Working Group


Appendix C: The differences between WCAG 1.0 and WCAG 2.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, when it eventually becomes a W3C Recommendation:
    * 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 
<http://www.w3.org/WAI/GL/WCAG20/2002/08/20-mapping.html>Checkpoint Mapping 
Between WCAG 1.0 and the WCAG 2.0 Working Draft.


Improvements in WCAG 2.0

We hope that WCAG 2.0 will have several improvements over WCAG 1.0. While 
the primary goal of WCAG 2.0 is the same as WCAG 1.0 (to promote 
accessibility of Web content) additional goals for WCAG 2.0 include 
improvements that will:
    * Ensure that requirements may be applied across technologies
    * Ensure that the conformance requirements are clear
    * Ensure that the deliverables are easy to use
    * Write to a more diverse audience
    * Clearly identify who benefits from accessible content
    * Ensure that the revision is "backward compatible" with WCAG 1.0
For more information about the intended improvements in WCAG 2.0 Working 
Draft, please refer to <http://www.w3.org/TR/wcag2-req/>Requirements for 
WCAG 2.0.


Appendix D: References

Reviewer's Note: Links within the document will be turned into references 
and the links to those documents will be listed here as references. They 
are inline for the time being.
Received on Thursday, 31 October 2002 20:31:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:20 GMT