- From: Weinland, Audrey <audrey.weinland@sap.com>
- Date: Thu, 31 Oct 2002 20:42:17 -0500
- To: w3c-wai-gl@w3.org
- Message-Id: <5.1.0.14.2.20021031204136.02519ec0@localhost>
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 UTC