[Contents] [Techniques] [Checklist]
This specification provides guidelines for designing Web content authoring
tools that are more accessible for people with disabilities. An authoring
tool that conforms to these guidelines will promote accessibility by providing
an accessible user interface to authors with disabilities as well as enabling,
supporting, and promoting the production of accessible Web content by all
authors.
"Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0)
is part of a series of accessibility guidelines published by the W3C Web
Accessibility Initiative (WAI).
May be Superseded
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current
W3C publications and the latest revision of this technical report can be
found in the W3C technical reports index at
http://www.w3.org/TR/.
Editor's Draft of ATAG 2.0
This is an internal Editor's Draft.
The Working Group (AUWG) intends
to publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring
Tool Accessibility Guidelines 1.0 (ATAG 1.0) [ATAG10] is
the stable, referenceable version. This Working Draft does not supersede
ATAG 1.0.
Web Accessibility Initiative
This document has been produced as part of the W3C Web
Accessibility Initiative (WAI). The goals of the AUWG are discussed
in the Working Group charter.
The AUWG is part of the WAI
Technical Activity.
No Endorsement
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Patents
This document was produced by a group operating under the 5
February 2004 W3C Patent Policy. W3C maintains a public
list of any patent disclosures made in connection with the deliverables
of the group; that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the individual
believes contains Essential
Claim(s) must disclose the information in accordance with section
6 of the W3C Patent Policy.
This section is informative, except where
noted.
This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version
2.0. This document includes recommendations for assisting developers to make their authoring tools more accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech difficulties, and others. However, even authoring tools that conform to ATAG may not be fully accessible to every person with a disability. In order to achieve accessibility authoring tools must address the needs of two (potentially overlapping) user groups:
- authors of Web
content, whose needs are met by ensuring the authoring
tool user interface itself is accessible (see Part
A of the guidelines), and
- end
users of Web content, whose needs are met by ensuring that all authors are enabled, supported, and guided towards producing accessible Web content, with the assumption that many authors will not be familiar with the specific needs of
end users with disabilities.
The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people with disabilities than on other people.
Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by ATAG 2.0, either directly or through assistive technologies, the ATAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.
These guidelines have been written to address the requirements
of many different audiences, including, but not limited to:
- authoring tool developers,
- authoring tool users (authors),
- authoring tool purchasers, and
- policy makers.
Definition of authoring
tool
This section is normative.
ATAG 2.0 defines an "authoring tool" as any software, or collection
of software components, that authors use
to create or modify Web
content for
publication.
For examples of the range of software covered by this definition, see the examples in the definition of editing view.
Components of Web Accessibility
Authoring Tools are just one aspect of accessibility. For an overview of the different components of accessibility and how they work together see:
Organization of the ATAG 2.0 Document
The Guidelines
The guidelines are divided into two parts, each reflecting a key aspect
of accessible authoring tools. Part A includes
principles and associated guidelines that are related to ensuring accessibility
of the authoring
tool user interface. Part B contains
principles and guidelines related to ensuring support by authoring tools for the creation of accessible
Web content by any author (not just those with disabilities) to end
users with disabilities.
Part A: Make the authoring tool user
interface accessible
The guidelines and success criteria in Part A are organized around the following four principles, adapted from the four principles in WCAG 2.0:
- Authoring tool must facilitate access by assistive technology - Assistive technologies can only provide augmented display and control to their
users if the relevant information is made available by authoring tools
using common protocols.
- Authoring tool must be perceivable - Authors with a wide range of abilities must be able to perceive its user interface controls.
- Authoring tool must be operable - Authors with a wide range of abilities must be able to operate its user interface controls.
- Authoring tool must be understandable - Authors with a wide range of abilities must be able to understand the user interface controls that they can perceive and operate.
Part B: Support the production
of accessible content
There are three principles in Part B:
- Production
of accessible content must be enabled - The creation of accessible content is dependent on the combined actions of the
tool and the author. This guideline delineates the responsibilities that
rest exclusively with the tool.
- Authors must be supported
in the production of accessible content - Actions may be taken at the author's initiative that may result in accessibility
problems. The authoring tool should include features that provide
support and guidance to authors in
these situations, so that accessible
authoring practices can be followed and accessible
web content can be produced.
- Accessibility
solutions must be promoted and integrated - This guideline includes guidelines that require
authoring tools to raise the profile of accessible authoring, while
at the same time, integrating functions related to accessibility in
order to encourage authors to make them common practice.
Note: While the requirements in this part do not
deal with the accessibility of the authoring tool user interface, it should
be noted that any of the features (e.g., checker, tutorial) added to meet
Part B must also meet the user interface accessibility requirements of Part
A.
Success Criteria
Under each guideline there are success criteria that describe specifically what must be achieved in order to conform . They are similar to the "checkpoints" in ATAG 1.0. Each success criterion is written as a statement that will be either true or false when a specific authoring tool is tested against it.
All ATAG 2.0 success criteria are written to be testable. While some can be tested by computer programs, others require human testers for part or all of the test.
Each success criterion for a guideline has a link to the Techniques document that provides:
- sufficient techniques for meeting the success criterion, and
- optional advisory techniques.
Success Criteria Levels
ATAG 2.0 success criteria are organized into three levels of conformance.
- Level A:
- For success criteria in Part A:
- These success criteria achieve accessibility by supporting assistive
technology while putting the fewest possible limits on tool design.
Thus people with a wide range of disabilities using a wide range
of assistive technologies, from voice input and eye-tracking devices
to screen readers and screen magnifiers, are able to access tools
in different ways.
- For success criteria in Part B:
- Level AA:
- For success criteria in Part A:
- These success criteria provide additional support for assistive
technology. At the same time, they also support more direct access
to content by the many people who use authoring tools
without assistive technology. In general, Level AA success criteria
place more limits on tool design than Level A success criteria in Level.
- For success criteria in Part B:
- Level AAA:
- For success criteria in Part A:
- These success criteria increase both direct access and access
through assistive technology. They place even tighter limits on
tool design.
- For success criteria in Part B:
Note: If a guideline success criterion is not applicable
to an authoring tool, then that success criterion is treated as satisfied for
conformance purposes as long as a rationale is provided.
Levels of conformance
Authoring tools may claim full conformance
to ATAG 2.0 at one of three conformance levels. The level achieved depends
on the level of the success
criteria that have been satisfied. The full conformance
levels are:
- Full ATAG 2.0 Conformance at Level "A"
The authoring tool satisfies all of
the Level A success criteria.
- Full ATAG 2.0 Conformance at Level "Double-A"
The authoring tool satisfies all of
the Level A and Level
AA success criteria.
- Full ATAG 2.0 Conformance at Level "Triple-A"
The authoring tool satisfies all of
the success criteria.
In addition, a Partial Conformance claim option is available
in cases where an authoring tool has satisfied all of the success criteria
at a specified level in one of the two Parts of the document (i.e. "Part
A: Make the authoring tool user interface accessible" and "Part
B: Support the production of accessible content"). The partial
conformance levels are:
- Partial ATAG 2.0 Conformance Level "A":
Authoring Tool User Interface
The authoring tool satisfies all of the Level
A success criteria in Part A. Nothing is claimed about Part B.
- Partial ATAG 2.0 Conformance Level "Double-A":
Authoring Tool User Interface
The authoring tool satisfies all of the Level
A and Level AA success criteria in Part A. Nothing
is claimed about Part B.
- Partial ATAG 2.0 Conformance Level "Triple-A":
Authoring Tool User Interface
The authoring tool satisfies all of the success criteria
in Part A. Nothing is claimed about Part B.
- Partial ATAG 2.0 Conformance Level "A":
Content Production"
The authoring tool satisfies all of the Level
A success criteria in Part B. Nothing is claimed about Part A.
- Partial ATAG 2.0 Conformance Level "Double-A":
Content Production"
The authoring tool satisfies all of the Level
A and Level AA success criteria in Part B. Nothing
is claimed about Part A.
- Partial ATAG 2.0 Conformance Level "Triple-A":
Content Production"
The authoring tool satisfies all of the success criteria
in Part B. Nothing is claimed about Part A.
Note: The Working Group remains committed
to the guiding principle that: "Everyone should
have the ability to create and access Web content". Therefore, it is
recommended that Partial Conformance be claimed as a step towards full conformance.
Relationship
to the Web Content Accessibility Guidelines (WCAG)
The ATAG 2.0 conformance model relies upon Web
Content Accessibility "Benchmark" documents to precisely specify what an evaluator interprets "Accessible
Web Content" to mean for the Web content technologies that an authoring tool produces and/or is implemented using.
The recommended reference for the Web
Content Accessibility "Benchmark" is the W3C-WAI Web Content Accessibility Guidelines due to the quality of the documents and the process under which they were developed (See Note on other Accessibility Standards). At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10], and a second version of the guidelines is under development [WCAG20]. Although a Web
Content Accessibility "Benchmark" document may use either version of WCAG, developers should give consideration to the following when deciding which WCAG version to use in a product:
- The latest version of WCAG will be the most accurate with respect to
state-of-the-art technologies and accessibility best practices. Older versions
of WCAG may include requirements that are no longer necessary, due to advances
in user agent technology.
- The versions of WCAG differ with respect to the formats
for which there are published WCAG technique documents. This is important
because the techniques documents may be useful when constructing Web Content
Accessibility "Benchmark" documents as required by ATAG 2.0.
- The versions of WCAG differ in the degree to which they match the legislation
and policies that drive author requirements. Many authors will be seeking
to use authoring tools to create Web content that meets legislation, corporate
policies, etc. It is likely that as WCAG progresses, so too will legislation
and policies, albeit at an uneven pace. Authoring tool developers may,
therefore, consider supporting both versions of WCAG in
the interim.
ATAG 2.0 Guidelines
This section is normative.
PART A:
Make the authoring tool user interface accessible
PRINCIPLE
A.1: Authoring tool must facilitate access
by assistive technologies
Guideline A.1.1
[For the authoring tool user interface] Ensure Web-based
functionality is accessible.
[Techniques]
Rationale: In
addition to generally improving the accessibility of the authoring
tool user interface, implementing Web-based functionality (e.g., editing views, documentation) using
accessible Web content facilitates communication with assistive
technologies via user agents.
Note 1: This guideline does not apply to non-Web-based authoring tool user interface functionality.
Note 2: This guideline does not apply to *Content Renderings* if the accessibility problems are due to accessibility problems in the content being edited.
Level A Success Criteria for Guideline A.1.1
Level AA Success Criteria for Guideline A.1.1
Level AAA Success Criteria for Guideline A.1.1
Guideline A.1.2
[For the authoring tool user interface] Support interoperability with
assistive technologies. [Techniques]
Rationale: Assistive
technologies that are used by many people with disabilities (e.g.,
screen readers, screen magnifiers, on-screen
keyboards, voice recognition systems) rely on the authoring
tool to provide data and control via prescribed communication protocols (e.g., accessibility platform architectures).
Note: This guideline does not apply to Web-based authoring tool user interface functionality.
Level A Success Criteria for Guideline A.1.2
- A.1.2.1 Accessibility Platform Architecture (user interface "chrome", content display): Non-Web-based authoring user interfaces must implement
an existing accessibility platform architecture relevant to the platform.
- A.1.2.2 Unsupported Functionality (user interface "chrome", content display): If any non-Web-based authoring user interface functionality is not supported by the implemented accessibility
platform architecture(s), then either of
the following must be true:
- Accessible Alternative: a separate accessible
alternative for that functionality that is supported by the
implemented accessibility
platform architecture(s) is provided and a
description of the inaccessible functionality appears in the conformance claim, or
- Additional Interoperability Mechanism: an alternative interoperability mechanism
(e.g., an extension to the implemented accessibility
platform architecture(s)) that enables the functionality
to be available to an assistive technology that supported the
mechanism is implemented and publicly documented.
Level AA Success Criteria for Guideline A.1.2
- A.1.2.3 Deviation from Proper Use (user interface "chrome", content display): If any non-Web-based authoring user interface functionality deviates from the proper use of the implemented accessibility
platform architecture(s) (i.e., lack of use, incomplete
use, inappropriate use) as defined by the documentation for
the accessibility
platform architecture(s) must be documented with the conformance
claim.
Level AAA Success Criteria for Guideline A.1.2
- A.1.2.4 Additional Information (user interface "chrome", content display): For non-Web-based authoring user interfaces, additional information must be
published describing the nature of the implementation of the accessibility
platform architecture(s) (e.g., that the long description is different from
the associated tool tip).
Guideline A.1.3 [For the authoring tool user interface] Follow the accessibility conventions
of the platform.
[Techniques]
Rationale: Following platform accessibility conventions lessens the need for assistive technologies to make special-purpose accommodations. Also, people who are familiar with the accessibility conventions employed by
a specific platform will find application that adhere to those conventions easier to use .
@@GP: I would like to see a > requirement for claimants to cite the authority for the conventions > being followed. "My application adheres to Windows UI conventions > version xxx, or Mac OS X, or X Windows, etc.
Level A Success Criteria for Guideline A.4.1
- A.4.1.1 Focus and Selection Conventions (user interface "chrome", content display): Focus and selection conventions for the platform must be followed.
- A.4.1.2 Keyboard Conventions (user interface "chrome"): Keyboard accessibility configuration conventions (e.g., default
accelerator key bindings) for the platform must be
followed.
- A.3.1.4 Platform Keyboard Accessibility Features (user interface "chrome"): Keyboard
accessibility features of the platform (e.g.,
StickyKeys, SlowKeys, browser link navigation) must not be interfered with. @@moved here from A.3.1@@
Level AA Success Criteria for Guideline A.4.1
- (No level AA success criteria for Guideline A.4.1)
Level AAA Success Criteria for Guideline A.4.1
- (No level AAA success criteria for Guideline A.4.1)
PRINCIPLE
A.2: Authoring Tool User Interface must be Perceivable
Guideline A.2.1
[For the authoring tool user interface] Display text
alternatives for non-text
objects. [Techniques]
Rationale: People
who have difficulty perceiving non-text objects are often able to
access text alternatives of the same information because there are a variety of ways to display text (e.g., magnification, enhancement, text-to-speech, Braille output)
Level A Success Criteria for Guideline A.2.1
- A.2.1.1 Editing Non-text Objects (content display): All editing
views that render non-text
objects contained within the content being
edited must be able to display any text
alternatives that are identifiable by the authoring tool. It is permissible for the authoring
tool to automatically change editing views to display the text
alternatives (e.g., from WYSIWYG to code-level).
- A.2.1.2 Non-text Objects (user
interface "chrome"): All non-text
objects in the "chrome" must have text
alternatives that present equivalent information, except for the situations listed below.
- Controls-Input: If a non-text object is a control or accepts user input, then it has a name that describes its purpose.
- Media, Test, Sensory: If non-text object is multimedia, live audio-only or live video-only content, a test or exercise that must be presented in non-text format, or primarily intended to create a specific sensory experience, then text alternatives at least identify the non-text content with a descriptive text label.
- CAPTCHA: If the purpose of a non-text object is to confirm that content is being accessed by a person rather than a computer, then a descriptive text label describing its purpose is provided and different forms are provided to accommodate different disabilities.
- Decoration, Formatting, Invisible: If a non-text object provides no information or functionality, or is used only for visual formatting or is not presented to users, then it is implemented such that it can be ignored by assistive technology.
Level AA Success Criteria for Guideline A.2.1
- (No level AA success criteria for Guideline A.2.1)
Level AAA Success Criteria for Guideline A.2.1
- (No level AAA success criteria for Guideline A.2.1)
Guideline A.2.2
[For the authoring tool user interface] Display synchronized
alternatives for multimedia.
[Techniques]
Rationale: People
who have difficulty accessing or interpreting multimedia can have the information
made available to them by other means. For example, people who are
deaf or have a hearing loss can access auditory information through
captions. People who are blind or have low vision, as well as
those with cognitive disabilities, who have difficulty interpreting
visually what is happening, can receive audio descriptions of visual
information.
Level A Success Criteria for Guideline A.2.2
- A.2.2.1 Editing Multimedia (content
display): All editing
views that render multimedia contained within the content being
edited must be able to display any synchronized
alternatives that are identifiable by the authoring tool. It is permissible
for the authoring tool to change editing
views to display the synchronized alternatives. @@Moved to A from AA@@
- A.2.2.2 Audio Information (user interface "chrome"): If prerecorded multimedia (e.g., a tutorial video) is present, then at least one of the following must be true:
- A.2.2.3 Visual Information (user interface "chrome"): If prerecorded multimedia is present,
then at least one of the following must be true:
- Audio Track: all of the information in the video track is provided in the audio track,
- Audio Descriptions: audio descriptions are provided, or
- Accessible Alternatives: accessible alternatives to multimedia are provided.
Level AA Success Criteria for Guideline A.2.2
- A.2.2.4 Captions (user interface "chrome"): If prerecorded multimedia is present, then captions must be provided.
- A.2.2.5 Audio Description (user interface "chrome"): If prerecorded multimedia is present, then at least one of the following must be true:
- Audio Track: all of the information in the video track is provided in the audio track, or
- Audio Descriptions: audio descriptions are provided.
Level AAA Success Criteria for Guideline A.2.2
- A.2.2.6 Sign Language (user interface "chrome"): If prerecorded multimedia is present, then sign language interpretation must be provided.
- A.2.2.7 Accessible Alternative (user interface "chrome"): If prerecorded multimedia is present, then accessible alternatives to multimedia must be provided.
Guideline A.2.3
[For the authoring tool user interface] Ensure that the interface can be presented in different ways without losing information or functionality . [Techniques]
Rationale: Authors need to have access to both the functional significance of presentation and also, in the context of authoring, to the presentation that will be experienced by the end user.
Level A Success Criteria for Guideline A.2.3
- A.2.3.1 Purpose of Controls (user
interface "chrome"): Controls must have their functional purposes made available via the platform.
- A.2.3.2 Purpose of Added Presentation (content
display): If the authoring tool modifies the presentation of the content being edited, then the functional
purpose for the modification must be made available via the platform (e.g., that text is misspelled).
- A.2.3.3 Access to Presentation Being Edited (content
displays): If an editing view (e.g., WYSIWYG) renders any of the following text presentation characteristics and those characteristics are editable by any editing view (e.g., code-level), then the characteristics must be made
available via the platform:
- (a) font,
- (b) style (e.g., italic, bold),
- (c) color, and
- (d) size
- A.2.3.4 Meaningful Sequence (user
interface "chrome"): When the presentation sequence of controls affects their meaning, both of the following must be true:
@@WCAG2 Synch@@
- Reading Sequence: a correct reading sequence is available via an accessibility platform architecture.
- Navigation Sequence: sequential navigation of the controls is consistent with that sequence.
- A.2.3.5 Size, Shape, Location (user
interface "chrome"): Instructions provided for understanding and operating the authoring tool do not rely on shape, size, visual location, or orientation of components. @@WCAG2 Synch@@
Level AA Success Criteria for Guideline A.2.3
- (No level AA success criteria for Guideline A.2.3)
Level AAA Success Criteria for Guideline A.2.3
- A.2.3.6 Access to Presentation Being Edited (content
displays): Any presentation (text size,
positioning, etc.) that is rendered in an editing view (e.g., WYSIWYG) and editable by any editing view, must be available via an accessibility
platform architecture
Guideline A.2.4
[For the authoring tool user interface] Provide display
flexibility. [Techniques]
Rationale: ??? Authors require access the display settings that differ from the
presentation that they intend to define for the published content
(e.g., using a high contrast setting during editing content that is
not high contrast).
Note: While the
success criteria for this guideline are based on the capabilities
of the platforms (e.g.,
operating systems, user agents, GUI toolkits) listed in the conformance
profile, additional configuration settings may be provided.
Level A Success Criteria for Guideline A.2.4
- A.2.4.1 Use of Color (user interface "chrome", content display): If the authoring tool uses information that is conveyed by color differences to communicate about its operation (as opposed to rendering content being edited) (e.g., red font to highlight code containing a syntax error), then the same information must also be conveyed in a way that is simultaneously visually evident without the color differences.@@combination of A.2.4.1 and A.2.4.2
- A.2.4.2 Visual Display (user interface "chrome", content display): If a visual display is provided, authors must be able to configure the visual display settings by at least one of the following methods:
- Platform Settings: an option to inherit the platform settings,
or
- Tool Specific Settings: content display settings specific to the authoring tool.
- A.2.4.3 Audio Display (user interface "chrome", content display): If an audio display is provided, authors must be able to configure the audio display settings by
at least one of the following methods:
- Platform Settings: an option to inherit the platform settings,
or
- Tool Specific Settings: content display settings specific to the authoring tool.
- A.2.4.4 Audio Turnoff (user
interface "chrome", content display): If any audio can play automatically for more than 3 seconds, then at least one of the following must be true:
@@WCAG2 synch@@
- Pause/Stop: a mechanism is available to pause or stop the audio, or
- Independent Volume: a mechanism is available to control audio volume which can be set independently of the system volume.
- A.2.4.5 Images of Text Contrast (user
interface "chrome"): Images of text must have a contrast ratio of at least 5:1 (except if pure decoration).@@WCAG2 synch@@
- A.2.4.6 Independence of Display (content
display): Editing
views that usually have their display characteristics set
by rendering the content being
edited (e.g., WYSWYG) must include an option to have the
visual and audio display settings override these characteristics without
affecting the content (e.g.,
markup, stylesheets, etc.) being edited.@@WCAG2 synch@@
Level AA Success Criteria for Guideline A.2.4
- A.2.4.7 Visual Configurability (user
interface "chrome", content display): If the visual display
settings are not inherited from the platform settings, then the authoring tool must
provide at least comparable configurable properties with at least
comparable configuration ranges as the platform provides.
- A.2.4.8 Audio Configurability (user
interface "chrome", content display): If the audio display
settings are not inherited from the platform settings, then the authoring tool must provide at least comparable configurable properties with at least
comparable configuration ranges as the platform provides.
- A.2.4.9 Resize Editable Content (content
display): Rendered editing views must allow the content being edited to be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality. @@WCAG2 synch@@
Level AAA Success Criteria for Guideline A.2.4
- A.2.4.10 Images of Text Contrast (user
interface "chrome"): Images of text must have a contrast ratio of at least 7:1 (except if pure decoration).@@WCAG2 synch@@
- A.2.4.11 Low or No Background Audio (user
interface "chrome"): Audio that contains speech in the foreground must not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sound effects. Note: Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content.@@WCAG2 synch@@
PRINCIPLE
A.3: Authoring Tool User Interface must be Operable
Guideline A.3.1
[For the authoring tool user interface] Ensure all functionality
is available from a keyboard. [Techniques]
Rationale: Providing alternate keyboard accessibility provides access for people with limited mobility and people with
visual disabilities, who cannot rely on hand-eye coordination for
navigating the user interface.
Notes: This guideline should not discourage the
support of other input methods (such as a mouse) in addition to
keyboard operation. Also see Guideline
A.3.1 when choosing keystrokes.
Note: Web-based authoring tool user interface functionality may rely on the keyboard
navigation functions of the user
agent listed in the conformance
profile to satisfy some of these success criteria.
Level A Success Criteria for Guideline A.3.1
- A.3.1.1 Keyboard (user interface "chrome", content display): Authors must be
able, through keyboard input alone, to navigate to and operate all of the functions included in the authoring
tool user interface (e.g., navigating, selecting, and editing content within editing
views, operating the user interface "chrome", installing
and configuring the tool, and accessing documentation), except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. freeform drawing). This applies to at least one mechanism per authoring outcome, allowing
non-keyboard accessible mechanisms to remain available (e.g.,
providing resizing with mouse-"handles" and with a properties
dialog).
- A.3.1.2 Separate Activation (user interface "chrome", content display): Authors must have
the option to have selection separate from activation
(e.g., navigating through the items in a dropdown menu without
activating any of the items).
- A.3.1.3 Available Keystrokes (user interface "chrome", content display): The author must be able to determine currently available
keystrokes at
all times (e.g., from a central location such as a list in the
help system or a distributed location such as associating shortcuts
with menu items).
- A.3.1.4 Standard Text Area Conventions (content
display): Editing
views that allow text entry must support the standard text area conventions for
the platform including, but not necessarily limited to:
character keys, backspace/delete, insert, "arrow" key
navigation, page up/page down, navigate to start/end, navigate
by paragraph, shift-to-select mechanism, etc.
- A.3.1.5 "Chrome" Navigation (user interface "chrome"): Authors must be able to use the keyboard to traverse all of the controls forwards and backwards, including controls in floating toolbars, panels, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab").
Level AA Success Criteria for Guideline A.3.1
- A.3.1.6 Accelerator Keys (user interface "chrome"): If any of the following functionalities are implemented by the
authoring tool, the author must have the option to enable
key-plus-modifier-key (or single-key) access to them:
- (a) open help system,
- (b) open new content,
- (c) open existing content,
- (d) save content,
- (e) close content,
- (f) cut/copy/paste,
- (g) undo/redo, and
- (h) open find/replace function.
Level AAA Success Criteria for Guideline A.3.1
- A.3.1.7 Intergroup Navigation (user interface "chrome", content
display): If logical groups of focusable controls (e.g., toolbars, dialogs, labeled groups, panels) are present, authors must be able to use the keyboard to navigate to a focusable control in the next and previous groups.
- A.3.1.8 Group Navigation (user interface "chrome", content
display): If logical groups of focusable controls are present, authors must be able to use the keyboard to navigate to the first, last, next and previous focusable controls in the current group.
Guideline A.3.2
[For the authoring tool user interface] Ensure authors can configure
access to selectable
items @@main menu item or maybe remove Guideline completely?@@. [Techniques]
Rationale: People
who have limited mobility benefit from quick access to the items that
they use frequently.
Level A Success Criteria for Guideline A.3.2
- (No level A success criteria for Guideline A.3.2)
Level AA Success Criteria for Guideline A.3.2
Level AAA Success Criteria for Guideline A.3.2
- A.3.2.2 Customizable (user interface "chrome"): At least one control container (e.g.,
toolbar) in which selectable
items can be activated by a single action must be provided,
where both of the following are true:
- Membership: authors can
select which items are included
in the container, from the set of all selectable
items, and
- Order: authors can modify the
order that the items appear in the container.
Guideline A.3.3
[For the authoring tool user interface] Ensure authors can control time limits.
[Techniques]
Rationale: People
who have difficulty typing, operating the mouse, or processing information
can be prevented from using systems with short time limits.
Level A Success Criteria for Guideline A.3.3
- A.3.3.1 No Lost Data: If an authoring tool ends an authoring session due to a time limit (e.g., authenticated session expires), then the content being edited must not be lost. For Web-Based Authoring Tools this applies to any content submitted to the application by the user agent.
- A.3.3.2 Timing: If the authoring tool imposes time limits on authoring sessions (e.g., to mediate collaborative
authoring), then authors must have the option of setting the time limit to be at least five times the length of the default setting.
- A.3.3.3 Moving Targets (user interface "chrome"): If controls that act as targets for author actions (e.g., are clickable, accept drag-and-drp actions) are capable of movement, then the author must be able to stop that movement.
Level AA Success Criteria for Guideline A.3.3
- A.3.3.4 Timing: If the authoring tool imposes time limits on authoring sessions (e.g., to mediate collaborative
authoring), then authors must have the option of setting the time limit to be at least ten times the length of the default setting.
Level AAA Success Criteria for Guideline A.3.3
- A.3.3.5 No Time Limits: Authoring tool must not impose time limits on authoring sessions.
Guideline A.3.4
[For the authoring tool user interface] Ensure authors can avoid flashing that could cause seizures. [Techniques]
Rationale: Flashing
can cause seizures in people with photosensitive epilepsy.
Level A Success Criteria for Guideline A.3.4
- A.3.4.1 Escape Rendered Flashing (content
display): If an editing
view (e.g., WYSIWYG) is capable of rendering content that
violates the general
flash or red flash thresholds, then the authoring tool must include both of
the following:
- Escape: a simple escape action (e.g. "Escape" key)
that allows authors to do one of
the following:
- i. switch to a mode in the current editing
view in
which flashing that violates the general
flash or red flash thresholds no longer occurs,
- ii. switch to an editing
view that does not render flashing content
(e.g., code-level) or
- iii. close the content.
- Escape Reminder: an option to turn on a reminder to authors of
the simple escape action (see (a) above), whenever
any content is opened, in case flashing does appear.
- A.3.4.2 Below Threshold (user
interface "chrome"): There must not
be any violation of the general
flash or red flash thresholds.
Level AA Success Criteria for Guideline A.3.4
- A.3.4.3 Freeze Rendered Flashing (content
display): If an editing
view is capable of rendering content that
violates the general
flash or red flash thresholds, then the authoring tool must include an option to render this content such that flashing that violates the general
flash or red flash thresholds no longer occurs.
Level AAA Success Criteria for Guideline A.3.4
Guideline A.3.5
[For the authoring tool user interface] Provide
navigation and editing via content structure. [Techniques]
Rationale: People
who have difficulty typing or operating the mouse benefit when the structure that may be inherent
in certain content can be used to navigate more efficiently within editing views and to perform
edits.
Level A Success Criteria for Guideline A.3.5
- A.3.5.1 Edit by Structure (content
display): If an editing
view (e.g., code-level) displays a structured
element set, authors must be
able, with a simple action, to select
any element in
the set and perform editing functions (e.g., cut, copy, paste, presentation)
on that element, its contents, and its sub-elements.
Level AA Success Criteria for Guideline A.3.5
- A.3.5.2 Navigate Structure (content
display): If an editing
view displays a structured
element set, authors must be
able with a simple action to move
the editing focus from any element to
other elements in the set with any of the following
relationships (if they exist):
- Parent: the element immediately
above,
- Child: the first element immediately
below,
- Previous Sibling: the element immediately
preceding at the same level, and
- Next Sibling: the element immediately
following at the same level.
Level AAA Success Criteria for Guideline A.3.5
- (No level AAA success criteria for Guideline A.3.5)
Guideline
A.3.6 [For the authoring tool user interface] Provide
text search. [Techniques]
Rationale: People
who have difficulty typing or operating the mouse benefit from the ability to navigation to arbitrary points within editing views.
Note: Web-based authoring tool user interface functionality may rely on the "find" function of the user
agent listed in the conformance
profile to help perform the searches.
Level A Success Criteria for Guideline A.3.6
- (No level A success criteria for Guideline A.3.6)
Level AA Success Criteria for Guideline A.3.6
- A.3.6.1 Text Search (content
display): A text search function must be
provided that has access to any textual information (including
text content, text
alternatives for non-text
objects, metadata, markup) that is editable in any editing
view. It is permissible for the authoring tool to automatically
change editing views to display the search results (e.g.,
from WYSIWYG to code-level in order to search markup).
Level AAA Success Criteria for Guideline A.3.6
- (No level AAA success criteria for Guideline A.3.6)
Guideline A.3.7
[For the authoring tool user interface] Save preference settings. [Techniques]
Rationale: Providing
the ability to save and reload sets of keyboard and display preference
settings benefits people using multi-user tools as well as people who have needs that differ over time (e.g., due to fatigue).
Level A Success Criteria for Guideline A.3.7
- (No level A success criteria for Guideline A.3.7)
Level AA Success Criteria for Guideline A.3.7
- A.3.7.1 Save Settings (user
interface "chrome"): Preference settings must be stored for any of the following that the authoring tool controls:
Level AAA Success Criteria for Guideline A.3.7
- A.3.7.2 Multiple Sets (user
interface "chrome"): Choosing between multiple sets of preferences (e.g., personal profiles,
personal settings) must be supported for any of the following that the authoring tool controls:
Guideline A.3.8
[For the authoring tool user interface] Ensure previews are
as accessible as existing user
agents. [Techniques]
Rationale: Preview features
are provided in many authoring tools because the workflow of
authors often includes periodically checking how content will appear
to end users in
a user
agent. Authors with disabilities need to be able to follow
the same workflow.
Notes: Previews are treated differently than editing views because authors, including those with disabilities, will not
be well-served if preview features
diverge too much from the actual functionality of available user
agents. Therefore, preview features are exempted from necessarily
having to meet all of the other requirements in Part
A of this
guidelines document, if they meet Guideline
A.3.8. Also the accessibility of the content
display of a preview will
be negatively affected if the content being rendered is inaccessible
or incomplete.
Level A Success Criteria for Guideline A.3.8
- A.3.8.1 Return Mechanism (user
interface "chrome"): If a preview is
provided, then a mechanism for returning
from the preview (i.e., moving focus back from, exiting from) must be
provided that meets Guideline A.3.1 and
is documented in the help system.
- A.3.8.2 Preview (user
interface "chrome", content
display): If a preview is
provided, then it must meet at least one of
the following:
- Existing User Agent: the preview makes
use of an existing user
agent (specified in the conformance
profile) (e.g., opening the
content in a third-party browser or browser component),
- Part A: the preview meets
all of the Level A guidelines in Part
A of these guidelines, or
- UAAG: the preview conforms
to a version of UAAG [UAAG].
Level AA Success Criteria for Guideline A.3.8
- (No level AA success criteria for Guideline A.3.8)
Level AAA Success Criteria for Guideline A.3.8
- (No level AAA success criteria for Guideline A.3.8)
PRINCIPLE
A.4: Authoring Tool User Interface must be Understandable
Guideline A.4.1 Make text content readable and understandable
Rationale: ???
Level A Success Criteria for Guideline A.4.1
- All logical groups (e.g, toolbars, dialogs, labelled groups) of focusable controls must provide a programmatically accessible (at least when any member of the group has focus) name (or description) for the group that describes the class of controls (ex, "clipboard access") that occur within it. If nested groups exists, each nested group needs its own name.
Level AA Success Criteria for Guideline A.4.1
- (No level AA success criteria for Guideline A.4.1)
Level AAA Success Criteria for Guideline A.4.1
- A.4.1.1 Language (user
interface "chrome"): The default human language can be programmatically determined.
- A.4.1.2 Unusual Words (user
interface "chrome"): A mechanism must be provided for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon.
- A.4.1.3 Abbreviations (user
interface "chrome"): A mechanism must be provided for finding the expanded form or meaning of abbreviations.
Guideline A.4.2
[For the authoring tool user interface] Make functionality predictable. [Techniques]
Rationale: People who may become easily disoriented benefit when
authoring tool user interfaces are consistent and predictable.
Level A Success Criteria for Guideline A.4.2
- A.4.2.1 On Focus (user
interface "chrome", content
display): The movement of focus between controls must not initiate a change of focus. @@WCAG2 Synch@@
- A.4.2.2 On Input (user
interface "chrome", content
display): Changing the setting of controls must not cause an automatic change of context unless the author has been advised of the behavior before using the component. @@WCAG2 Synch@@
Level AA Success Criteria for Guideline A.4.2
- A.4.2.3 Consistent Identification (user
interface "chrome"): Controls that have the same functionality within an authoring tool are identified consistently. @@WCAG2 Synch@@
Level AAA Success Criteria for Guideline A.4.2
Guideline A.4.3 [For the
authoring tool user interface] Provide an undo function. [Techniques] @@moved from A.3@@
Rationale: People who have difficulty making fine movements may be prone to making
unintended actions.
Note: It
is acceptable to collect text entry actions (e.g., typed words, a
series of backspaces) into a single author action.
Note: Web-based authoring tool user interface functionality may rely on the "undo" function of the user
agent listed in the conformance
profile perform the undo function for some editing actions
that do not involve server communication (e.g., typing in a
text area).
Level A Success Criteria for Guideline A.4.3
- A.4.3.1 Undo Content Changes (content
display): Author actions
that modify content must be
either reversible by an "undo" function or include a warning
to the author that the action is irreversible. An authoring
tool may have certain committing actions (e.g., "save" function)
that reset the undo history.
- A.4.3.1 Undo Setting Changes (user
interface "chrome"): Author actions
that modify authoring tool settings must be
either reversible by or include a warning
to the author that the setting modification is irreversible.
Level AA Success Criteria for Guideline A.4.3
Level AAA Success Criteria for Guideline A.4.3
- A.4.3.3 Multiple Undos (user
interface "chrome", content
display): If the most recent author
action is a reversible action,
an undo function must be provided that is able to reverse
at least 5 consecutive reversible actions.
Guideline A.4.4
[For the authoring tool user interface] Document the user interface
including all accessibility features. [Techniques]
Rationale: While
intuitive user interface design is valuable to many authors, some
people may still not be able to understand or be able to operate
the authoring tool user interface without proper documentation.
Level A Success Criteria for Guideline A.4.4
- A.4.4.1 Accessible Format (user
interface "chrome"): At least one
version of the documentation must either
be:
- Plain Text: plain text format,
- "A" Accessible: Web content and conform to a minimum
level of Web content accessibility (although it is not necessary
for the documentation to be delivered on-line), or
- Accessible Platform Format: not be Web content and conform to a published accessibility
benchmark that is identified in the conformance
claim (e.g.,
when platform-specific documentation systems are used).
- A.4.4.2 Document Accessibility Features (user
interface "chrome"): All features that are specifically required
to meet Part
A of these guidelines (e.g.
keyboard shortcuts, text search, etc.) must be documented.
Level AA Success Criteria for Guideline A.4.4
- (No level AA success criteria for Guideline A.4.4)
Level AAA Success Criteria for Guideline A.4.4
- A.4.4.3 Options Wizard (user
interface "chrome"): Provide an accessibility option-setting "wizard" in which the author determines which options within at least
Part A to activate.
Conformance
This section is normative.
Conformance means that the authoring
tool satisfies the success criteria defined in the guidelines section.
This conformance section describes conformance, lists the conformance requirements, and explains the important role of accessibility "benchmark" documents.
Web
Content Accessibility "Benchmark" Document
The purpose of the Web Content Accessibility "Benchmark" document
is to precisely specify the evaluator's interpretation of what "accessible
Web content" means with respect to the particular Web content technology or technologies that
are produced by the authoring tool or are used to implement Web-based user
interface functionality of the authoring tool (if applicable). This precise
interpretation helps the evaluator to judge the completeness and consistency
of accessibility-related authoring tool functions that must interoperate,
such as accessibility prompting, evaluation, and repair functions. In addition,
because the Benchmark must be made public, it allows claims to be more fully
checked for accuracy.
What does a Web Content Accessibility Benchmark document include?
A Benchmark document must be publicly published on the
Web (the URI will appear in the conformance
claim) under a license that permits it to be
copied (so that it can be included in other conformance claims), although not necessarily modified. The benchmark document must include:
- The name and version of the Web content technology or technologies covered
by the Benchmark document (e.g., "HTML 4.01" or "SVG 1.0
and PNG images") and optionally the URI of the specification(s). The
version may be a defined range.
- The version and URI of the Web content accessibility
standard that is being used as a basis for the Benchmark document
(e.g., "WCAG
2.0 Working Draft, http://www.w3.org/TR/WCAG20/") (See Note
on other Accessibility Standards).
- The target level of the Benchmark. This is
the level that would be met by Web content that implements
all of the benchmarks in the Benchmark document. There are three (3) possible
levels:
- Any assumptions about user agents available to authors or end users.
- The benchmarks:
For each normative requirement of the accessibility standard at the target
level, one of the following must be provided:
- at least one benchmark technique for meeting the normative requirement
using the Web content technology or technologies (e.g., HTML 4.01 benchmark techniques for
each WCAG 2.0 Level A success criteria), or
- an explanation of why that normative requirement is not applicable
to the Web content technology or technologies in question (e.g., for a text-only format, normative
requirements related to images would be considered not applicable)
Note
on other Accessibility Standards: ATAG 2.0 addresses how authoring
tools can be designed to encourage authors to create accessible content.
While the Working Group highly recommends the W3C-WAI Web Content Accessibility
Guidelines due to the quality of the document and the process under which
it was developed, other Recommendations, Standards, and Regulations with
the same goal exist in jurisdictions and organizations around the world.
Is a Web Content Accessibility Benchmark document normative?
A Web Content Accessibility Benchmark document may be based on informative documents,
such as WCAG Techniques, and should not therefore be considered "normative".
Instead, the document serves as a "relied upon" reference for a particular conformance
claim when it is included
in that claim. The reference helps
the evaluator to judge the completeness and consistency of accessibility-related
authoring tool functions that must interoperate, such as accessibility prompting,
evaluation, and repair functions.
Who can create a Web Content Accessibility Benchmark?
A Benchmark can be created by any any person, company or
other organization. However, in the interest of being able to directly compare
the evaluations of authoring tools that produce the same Web content technologies, the
Working Group suggests checking to see if a Benchmark document has already
been published, before creating a new one.
What resources are available to help create a Web Content
Accessibility Benchmark?
The Working Group suggests the following:
- WCAG Guideline documents:
- WCAG Technique documents:
- Understanding WCAG documents:
- W3C Access Note series:
- Web content technology specifications
Conformance
Claims
A conformance claim is an assertion by a claimant that an authoring
tool has satisfied the requirements of a chosen ATAG 2.0 conformance
profile.
Conditions on Conformance
Claims
- At least one version of the conformance claim must be published on the
Web as a document meeting level "A"
of Web content accessibility. A suggested metadata description
for this document is "ATAG 2.0 Conformance Claim".
- Whenever the claimed conformance level is published (e.g., in marketing
materials), the URI for the on-line published version of the conformance
claim must be included.
- The existence of a conformance claim does not imply that the W3C has
reviewed the claim or assured its validity.
- Claimants may be anyone (e.g., developers, journalists, other third parties).
- Claimants are solely responsible for the accuracy of their claims and
keeping claims up to date.
- Claimants are encouraged to claim conformance to the most recent version
of the Authoring Tool Accessibility Guidelines Recommendation that is available.
Required Components of an ATAG 2.0 Conformance Claim
- The date of the claim.
- The guidelines title, version, publishing date and status (e.g., "Authoring
Tool Accessibility Guidelines 2.0, 27 April 2007, Editor's Draft ")
- The name of the authoring tool and sufficient additional information
to specify the version (e.g., vendor name, version number, minor release
number, required patches or updates, natural language of the user interface
or documentation).
- The version information may be a range (e.g., "this
claim refers to version 6.x").
- If the authoring tool is a collection
of software components (e.g., a markup editor, an image editor,
and a validation tool), then information must be provided separately
for each component, although the conformance claim will treat them
as a whole.
- The conformance
profile, which must include the following:
- (a) The ATAG 2.0 conformance level that
has been satisfied (choose one of: "A", "Double-A", "Triple-A").
- (b) A list of the "benchmarked" Web content technologies produced
by the authoring tool. These are the only technologies covered by the claim.
- The list must include at least one Web content technology for the conformance
claim to be valid.
- When Web content technologies are typically produced together (e.g.,
HTML and JavaScript), they can be listed separately or together
in the list.
- Each Web content technology must include a Web
content accessibility benchmark document.
- (c) A list of any other Web content technologies produced by the authoring
tool that are not covered by the claim.
- (d) The platform(s) upon
which all or part (e.g., help system) of the authoring tool was evaluated:
- For user agent platform(s) used
to evaluate Web-Based user interface functionality, provide:
- The name and version information of the user
agent(s).
- The version and URI of the Web Content Accessibility Guidelines
document used to evaluate the accessibility of the Web-based
functionality.
- For platforms that are not user
agents, provide:
- The name and version information of the platform(s) (e.g.,
operating system, Java virtual machine, etc.).
- The name and version of the accessibility platform architecture(s)
employed.
Optional Components of an ATAG 2.0 Conformance Claim
- A description of the authoring tool that identifies the types of authoring
tool functions that are present in the tool. Choose one or more of: Code-level
authoring functions, WYSIWYG authoring functions, object
oriented authoring functions, or indirect authoring
functions.
- Any additional information about the tool, including progress towards
the next conformance level.
- A description of how the normative ATAG 2.0 success criteria were met
where this may not be obvious.
"Progress
Towards Conformance" Statement
Developers of authoring tools that do not yet conform fully to a particular
ATAG 2.0 conformance level are encouraged to publish a statement on progress
towards conformance. This statement would be the same as a conformance
claim except that this statement would specify an ATAG 2.0 conformance
level that is being progressed towards, rather than one already satisfied,
and report the progress on success criteria not yet met. The author of a "Progress
Towards Conformance" Statement is solely responsible for the accuracy
of their statement. Developers are encouraged to provide expected timelines
for meeting outstanding success criteria within the Statement.
Disclaimer
Neither W3C, WAI, nor WAI-AUWG take any responsibility for any aspect or result of any ATAG 2.0 conformance claim or Web Content Accessibility Benchmark document that has not been published under the authority of the W3C, WAI, or WAI-AUWG.
Appendix A: Glossary
This section is normative.
- abbreviations (adapted from WCAG 2.0 Glossary)
- A shortened form of a word, phrase, or name. This includes initialisms and acronyms.
- Initialisms: shortened forms of a name or phrase made from the initial letters of words or syllables contained in that name or phrase (e.g., ESP is an initialism for extrasensory perception).
- Acronyms: abbreviated forms made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word (e.g., WAI is an acronym made from the initial letters of the Web Accessibility Initiative).
- accessibility
platform architecture
- A programmatic interface that is specifically engineered
to enhance communication between mainstream software applications and assistive technologies (e.g., MSAA and IAccessible2
for Windows applications, Gnome Accessibility Toolkit API for Gnome, Java
Access for Java applications).
- accessibility
problem
- ATAG 2.0 refers to two types of accessibility problems:
- authoring tool user interface accessibility
problem: An aspect of
an authoring
tool user interface that does not to meet one of the guideline success
criteria in Part A. The severity of
a given problem is reflected in the level of the failed success criteria. @@investigate use@@
- Web content accessibility
problem: An aspect of Web
content that does not meet some accessibility
requirement. The severity of a given problem is relative
and is determined by the accessibility standard referenced by the Web
content accessibility benchmark.
- accessibility
information
- Any information
that is necessary for undertaking an accessible
authoring practice (e.g., equivalent
alternatives, relationships within complex tables).
- accessible
content support features
- Any features of an authoring tool that directly support authors in increasing the accessibility of the content being authored. Specifically, this will include any functionality that is used to meet the success criteria for B.2.1, B.2.2, B.2.3, B.2.4, B.2.5 and B.2.6.
- assistive technology (adapted from WCAG 2.0 Glossary and UAAG 1.0 Glossary)
- Software or hardware that provides services to meet the requirements of users with disabilities that go beyond direct accessibility features offered by mainstream software applications and hardware. Such services include alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible). Examples of assistive technologies that are important in the context of this document include the following:
- screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order improve the visual readability of rendered text and images;
- screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
- text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
- voice recognition software, which may be used by people who have some physical disabilities;
- alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard;
- alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
- Note: Mainstream software applications and hardware may also provide services directly that meet the requirements of users with disabilities.
- audio
description - also called described video, video description and descriptive narration (adapted from WCAG 2.0 Glossary)
- An equivalent
alternative that takes the form of narration added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone. Audio description of video provides information about actions, characters, scene changes, on-screen text, and other visual content. In standard audio description, narration is added during existing pauses in dialogue. In extended audio description, the video is paused so that there is time to add additional description.
- authors
- The users of authoring tools. This
may include content authors, designers, programmers, publishers, testers,
etc. working either alone or collaboratively.
- authoring
action
- Any action that authors take
using the authoring
tool user interface with the intention of editing content (e.g., typing text, deleting, inserting an element, applying a template). Most authoring tool user interfaces also enable actions that do not edit content (e.g., setting preferences for the tool, searching the help system).
- authoring
outcome
- A characteristic of content that
results from one or more authoring actions being applied.
Authoring outcomes exist at different levels (e.g., making a paragraph bold vs. deploying a site-wide navigation system) and are cummulative (e.g., text is entered, styled, made into a link, given title). Mainstream rendered authoring outcomes are only the subset of content characteristics that are apparent to end-users of mainstream user agents (e.g., text that is bold, a seamless patchwork of images; but not commented code or table relationships).
Often, multiple authoring practices exist that will result in the same mainstream rendered authoring outcome, but the outcomes may differ with respect to accessibility (e.g., text can be made bold using style sheets or using presentation markup).
- authoring
practice
- A technique that guides authors or
the authoring tool in selecting authoring actions to apply to content in order to achieve particular authoring outcomes. (e.g., controlling presentation with style sheets, commenting code, testing on multiple browsers). An accessible
authoring practice is one that seeks to avoid or correct one or more Web
content accessibility problems. Accessible authoring practices sometimes require accessibility
information.
- authoring
session
- A state of the authoring tool during which content can be edited by the author. The end of an authoring session is the point in time at which a session ends and the author has no further opportunity to make changes without starting another session. This may
be under the control of the author (e.g., closing a document, publishing) or it may be controlled by the authoring tool (e.g., when the authoring tool transfers editing permission to another author on a collaborative system).
- authoring
tool user interface (non-Web-based)
- Any part of an authoring
tool user interface that is not implemented as Web content and as a result runs directly on a non-user agent platform such as Windows, MacOS, Java Virtual Machine, etc.
- authoring
tool user interface (Web-based)
- Any part of an authoring
tool user interface, including editing views, documentation, etc., that is implemented using Web content technologies and is rendered by a user
agent. Since Web-based tools may be implemented in the Web content technologies that they are used to edit, the distinction between content
display and user interface "chrome" may
be less clear than with non-Web-based tools.
- authoring
tool user interface
- The
display and control mechanism that authors use
to communicate with and operate the authoring tool software. Authoring
tool user interfaces may be non-Web-based or Web-based or a combination of both (e.g., a stand-alone
markup editor with on-line help pages). Authoring tool user interfaces
can usefully be considered in two parts:
- content
display: Any parts of the user interface that are the rendered or unrendered content being edited.
Note: The authoring tool developer. Examples include:
- characters, words, commands, etc. appearing in a code-level editing
view,
- rendered text, images, tables, form controls, animations, sounds, etc. in a WYSIWYG editing
view,
- vector graphics with editing "handles", waveforms, etc. in an object-oriented editing
view,
- text entry characters and setting values in an indirect editing
view,
- rendered text, images, tables, form controls, animations, sounds, etc. in a preview.
- user
interface "chrome": The parts of the
user interface that are provided by the authoring tool developer. These may surround, underlie or super-impose upon the content
display or they may be completely separate. Examples include:
- surround the content display: menus, button
bars, palettes, help windows, cursors, dialog boxes, etc.,
- underlie the content display: (i.e. implementing
non-rendered part of editing views)
including text areas for a code-level editing
view, text boxes in an indirect editing
view, etc.,
- controls that are super-imposed upon content displays including
context menus on content, underlining problematic content, etc.
- separate:
- An accessible
authoring tool user interface ia one that meets the success criteria in Part
A (i.e. does not include any authoring tool user interface accessibility
problems). The level of accessibility is
determined by the levels of the satisfied success criteria.
- authoring tool
- See "Definition
of authoring tool".
- blink (adapted from WCAG 2.0 Glossary)
- Turn on and off between 0.5 and 3 times per second. The slower blink is in contrast with flashing, which refers to rapid changes in brightness which can cause seizures. See general flash and red flash thresholds.
- captions (adapted from WCAG 2.0 Glossary)
- An equivalent
alternative that takes the form of text presented and synchronized with multimedia to provide not only the speech, but also non-speech information conveyed through sound, including meaningful sound effects and identification of speakers.
- Note: In some countries, the term "subtitle" is used to refer to dialogue only and "captions" is used as the term for dialogue plus sounds and speaker identification. In other countries, "subtitle" (or its translation) is used to refer to both.
- checking (accessibility) - also
called accessibility evaluation (harmonized with EARL 1.0)
- The process by which Web
content is evaluated for Web
content accessibility problems. ATAG 2.0 identifies three types of
checking, based on increasing levels of automation of the tests:
- manual
checking: where the tests are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors must intervene to carry out the actual test procedure;
- semi-automated
checking: where the tests are partially carried out by the authoring tool, but where authors' input or judgment is still required to decide or help decide the outcome of the tests; and
- automated
checking: where the tests are carried out automatically by the authoring tool without any intervention by the authors.
An authoring tool may support any combination of checking types.
- collection
of software components
- Any software applications used either together (e.g., base tool
and plug-in) or separately (e.g., markup editor,
image editor, and validation tool), regardless of whether there has been
any formal collaboration between the developers of the applications.
- content generation
- ATAG 2.0 refers to two broad categories of content generation:
- author-generated content: When authors specify content (e.g.,
typing markup into a text editor, choosing an
element by name from a list, entering information into a dialog box).
- automatically-generated content: When the authoring tool specifies content (e.g., applying a template, automatically correcting markup errors, dynamically generated content).
- content (Web) - or shortened to content (adapted from WCAG 2.0 Glossary)
- Information and sensory experience to be communicated to the user by means of a user
agent, as well as code or markup that define the structure, presentation, and interactions associated with those elements. In ATAG 2.0, "content" is primarily
used in the context of the material in a Web content technology that is outputted by authoring
tools. This includes Web applications, including those that, in turn, act as Web-based authoring tools. accessible
Web content is Web content that does not contain accessibility
problems. Usually this refers to a particular level of accessibility (e.g., Web content that meets Level "A" Web content accessibility). Note: Accesible Web content is shorthand for content that meets a given set of accessibility criterie. This does not not necessarily mean that it will be accessible to every person with a disability.
- contrast ratio (adapted from WCAG 2.0 Glossary)
- (L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter of the foreground or background colors, and L2 is the relative luminance of the darker of the foreground or background colors.
- Note 1: Contrast ratios can range from 1 to 21 (commonly written 1:1 to 21:1).
- Note 2: For dithered colors, use the average values of the colors that are dithered (average R, average G, and average B).
- Note 3: Text can be evaluated with anti-aliasing turned off.
- Note 4: Background color is the specified color of content over which the text is to be rendered in normal usage. If no background color is specified, then white is assumed.
- Note 5: For text displayed over gradients and background images, authors should ensure that sufficient contrast exists for each part of each character in the content.
- conversion
- A process that takes as input, content in one Web content technology and produces as output, content in another technology (e.g., "Save as HTML" functions).
- direct accessibility
- Features of mainstream software applications and hardware that augment accessibility by people with disabilities (e.g., keyboard navigation, zoom functions, text-to-speech).
- display settings
- ATAG 2.0 refers to two types of display settings problems:
- display settings (audio): the characteristics of
audio output of music, sounds and speech and include volume, speech voices,
voice speed, and voice emphasis.
- display settings (visual): the characteristics of
the on-screen rendering of text and graphics and include fonts, sizes,
colors, spacing, positioning, and contrast.
- documentation
- Any information that supports the use of an authoring
tool. This information may be found electronically or otherwise and includes
help, manuals, installation instructions, sample workflows,
and tutorials, etc.
- editing
view
- A view provided
by the authoring tool that allows editing of
content by authors.
The authoring tool may
include more than one type of editing view (e.g., an HTML editor with both code-level and WYSIWYG editing
views. Types of editing views include:
- code-level editing views:
Authors have full control over all aspects
of the resulting Web content.
Includes plain text editors as well as editors that allow manipulation of symbolic representations that are sufficiently
fine-grained to allow authors the same freedom of control as plain
text editing (e.g., plain text editors enhanced with graphical tag placeholders). Examples include text
editors, text editors enhanced with graphical tags, some wikis, etc.
- WYSIWYG
("What-you-see-is-what-you-get") editing views: Authors
have control over entities that closely resemble the final appearance
and behavior of the resulting Web content. Examples include rendered
document editors, bitmap graphics editors, etc.
- object-oriented editing views: Authors have control over functional
abstractions of the low level aspects of the resulting Web content. Examples include timelines,
waveforms, vector-based graphic editors, objects which represent web
implementations for graphical widgets (e.g., menu widgets) etc.
- guided editing views: Authors only have control over relatively high-level
parameters that are used by the authoring tool to automatically generate the resulting Web
content. This allows the author to create
and organize Web content without having to author or even understand the underlying markup,
structure, or programming implementation. Often the user interface is a form that the author fills out. Examples include content
management systems, site building wizards, site management tools, courseware,
blogging tools, content aggregators, conversion tools, model-based
authoring tools, etc.
- element
- A pair of
tags and their content, or an "empty" tag - one that requires
no closing tag or content (used in the same sense as in HTML [HTML4] and XML)
- end user
- A person who interacts with Web
content once it has been authored. The author usually has the option to be the end user of the content they create, however some authoring tools increase the frequency of this switch (@@e.g., wikis).
- equivalent
alternative
- Content that is an acceptable substitute
for other content that a person may not be able to access. An equivalent
alternative fulfills essentially the same function or purpose as the original
content upon presentation: . Equivalent alternatives include text alternatives
and synchronized alternatives.
- text
alternative: programmatically determined text that is used in place of non-text content, or text that is used in addition to non-text content and referred to from the programmatically determined text. For example, an image of a chart is described in text in the paragraph after the chart and the short text-alternative for the chart indicates that a description follows. (adapted from WCAG 2.0 Glossary)
- full text alternative for multimedia including any interaction: document including correctly sequenced text descriptions of all visual settings, actions, speakers, and non-speech sounds, and transcript of all dialogue combined with a means of achieving any outcomes that are achieved using interaction (if any) during the multimedia. (adapted from WCAG 2.0 Glossary)
- synchronized
alternatives: present essential audio information visually (i.e., captions)
and essential video information in an auditory manner (i.e., audio
descriptions).
- freeform
drawing
- Drawing actions that use the mouse or stylus in a continuous fashion
(e.g., a paintbrush feature). This does not cover moving or resizing object-based
graphics (including moving or resizing an object that is a previously authored
freeform graphic).
- general
flash and red flash thresholds (adapted from WCAG 2.0 Glossary)
- A sequence of flashes or rapidly changing image sequences where all three of the following occur:
- there are more than three flashes within any one-second period,
- the flashing is below 50 Hz, and
- the combined area of flashes occurring concurrently and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field on the screen).
- Note 1: For the general flash threshold, a flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.
- Note 2: For the red flash threshold, a flash is defined as any transition to or from a saturated red.
- Note 3: For general Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances.
- inform
- To provide authors with information via the authoring tool user interface. Informing mechanisms range from unobtrusive (i.e., information presented without
stopping the authors' current activity) to intrusive (i.e., interrupting
the author's current activity). Information may be provided as part of a prompt.
- information that is conveyed by color differences(adapted from WCAG 2.0 Glossary)
- Information presented in a manner that depends entirely on the ability to perceive color.
- informative (adapted from WCAG 2.0 Glossary)
- For information purposes and not required for conformance.
- mainstream applications and hardware - also called mainstream technology
- Software applications and hardware for which augmenting accessibility is secondary to some other purpose (as opposed to assistive technology where it is the primary purpose). Mainstream technologies may include direct accessibility features.
- markup
- A set of tags from a markup
language.
Markup can be presentational (i.e., markup that encodes
information about the visual layout of the content), structural (i.e.,
markup that encodes information about the structural role of elements
of the content) or semantic (i.e., markup that encodes
information about the intended meaning of the content). A markup language is a syntax and/or set of rules to manage markup (e.g.,
HTML [HTML4], SVG [SVG], or MathML [MATHML]).
- mechanism (adapted from WCAG 2.0 Glossary) @@maybe this isn't needed@@
- A process or technique for achieving a result.
- Note 1: The mechanism may be explicitly provided in the authoring tool, or may be relied on to be provided by the platform.
- Note 2: The mechanism must meet all success criteria for the conformance level claimed
- multimedia (adapted from WCAG 2.0 Glossary)
- Audio or video synchronized with another format for presenting information and/or with time-based interactive components.
- non-text
objects
- Content objects that are not represented by text character(s) when rendered
in a user agent (e.g., images, audio, video).
- normative (adapted from WCAG 2.0 Glossary)
- Required for conformance.
- platform
- The software environment within which the authoring tool
operates. For non-Web-based authoring user interface functionality this will be an operating
system (e.g., Windows, MacOS, Linux), virtual machine (e.g., JVM) or a
higher level GUI toolkit (e.g., Eclipse). For Web-based authoring user interface functionality, "platform" applies more generically to user agents in
general, although for purposes of evaluating conformance to ATAG 2.0 a
specific user agent(s) will be listed in the conformance
profile.
- platform (available via)
- For non-Web-based authoring user interface functionality via
an implemented accessibility platform architecture. For Web-based authoring user interface functionality this means following relevant Web content accessibility design guidelines so that the user agent can pass on the information.
- plug-in
- A program that runs as part of the authoring
tool (e.g., a third-party evaluation and repair tool). Users generally
choose to include or exclude plug-ins from their authoring tool.
- presentation (adapted from WCAG 2.0 Glossary)
- Rendering of the content in a form
that can be perceived by authors.
- preview
- A non-editable view of the content that is intended to
show how it will appear and behave in a user
agent.
- prominence
- A heuristic measure of the degree to which authors are likely to notice controls in the authoring tool user interface when operating the authoring tool. In this document, prominence refers to visual as well as keyboard-driven navigation. Some of the factors that contribute to the prominence of a control include:
- control size (large controls or controls surrounded by extra white space may appear to be conferred higher importance),
- control order (items that occur early in the "localized" reading order (e.g., left to right and top to bottom; right to left and top to bottom) are conferred higher importance),
- control grouping (grouping controls together can change the reading order and the related judgments of importance),
- advanced options (when the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties may gain apparent importance), and
- highlighting (controls may be distinguished from others using icons, color, styling).
- prompt
- In this document "prompt" refers to any authoring tool initiated
request for a decision or piece of information from
authors. Well designed
prompting will urge, suggest, and encourage authors.
- publishing
- Making Web content available to end users (e.g., uploading a Web page, committing a change in a wiki).
- relative luminance (adapted from WCAG 2.0 Glossary)
- The relative perceived brightness of any point, normalized to 0 for black and 1 for maximum white.
- Note 1: The relative luminance of an sRGB color is defined as L = 0.2126 * R + 0.7152 * G + 0.0722 * B where R, G and B are defined as:
- if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4
- GsRGB <= 0.03928 then G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4
- if BsRGB <= 0.03928 then B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4
and RsRGB, GsRGB, and BsRGB are defined as:
- RsRGB = R8bit/255
- GsRGB = G8bit/255
- BsRGB = B8bit/255
The "^" character is the exponentiation operator. (Formula taken from [sRGB] and [IEC-4WD]).
- Note 2: Almost all systems used today to view Web content assume sRGB encoding. Unless it is known that another color space will be used to process and display the content, authors should evaluate using sRGB colorspace.
- Note 3: For dithered colors, use average values of the colors used (average R, average G, and average B).
- Note 4: Tools are available that automatically do the calculations when testing contrast and flash.
- repairing (accessibility) (harmonized with EARL 1.0)
- The process by which Web
content accessibility problems that have been identified within content are resolved. ATAG 2.0 identifies three types of repairing,
based on increasing levels of automation:
- manual: where the repairs are carried out by authors. This includes the case where the authors are aided by instructions or guidance provided by the authoring tool, but where authors carry out the actual repair procedure;
- semi-automated: where the repairs are partially carried out by the authoring tool, but where authors' input or judgment is still required to complete the repair; and
- automated: where the repairs are carried out automatically by the authoring tool without any intervention by the authors.
- reversible
actions
- Authoring actions that, by their nature,
can be completely undone so that the system returns to the state it was
in before the action. Actions that are not reversible may include certain
save and delete actions as well as actions made in a collaborative environment
that another author has begun to work with.
- selectable
items @@vague term...maybe "menu-type items"?@@
- Any items that an author may select from within the menus, toolbars,
palettes, etc. (e.g., "open", "save", "emphasis", "check
spelling")
- structured
element set
- Content that consists of organized elements (e.g., lists, maps, hierarchies, graphs).
- technology (Web content) - or shortened to technology (adapted from WCAG 2.0 Glossary)
- A mechanism for encoding instructions to be rendered, played or executed by user agents. Web Content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static Web pages to multimedia presentations to dynamic Web applications. Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript. A benchmarked Web content technology is one that is listed in the conformance profile and accompanied by a Web Content Accessibility Benchmark document. The level of accessibility listed in the benchmark document might also be referenced (e.g., level "AA" benchmarked technology).
- template selection mechanism
- A function that allows authors to select templates to use as the basis for new content or to apply to existing content.
- transcript
- A non-synchronized text
alternative for the sounds, narration, and dialogue in an audio clip
or the auditory track of a multimedia presentation. For a video, the
transcript can also include the description of actions, body language,
graphics, and scene changes of the visual track.
- transformation
- A process that takes content in one Web content technology as input and outputs different content in the same technology (e.g., a function that transforms tables into lists).
- tutorial
- A type of documentation that involves
the sequential presentation of instructions for performing multi-part tasks.
- user
agent (adapted from WCAG 2.0 Glossary)
- Any software that retrieves and presents Web content for end users. Examples include Web browsers, media players, plug-ins, and other programs including
assistive technologies, that help in retrieving, rendering and interacting with Web content.
- user interface component (adapted from WCAG 2.0 Glossary)
- A part of the content display or user interface "chrome" that is perceived by authors as a single control for a distinct function.
- video (adapted from WCAG 2.0 Glossary)
- The technology of moving pictures or images. Video can be made up of animated or photographic images, or both.
- view
- A rendering, playing or execution of content by an authoring tool. Authoring tool views are usually either editing
views or previews.
- workflow
- A customary sequence of steps or tasks authors follow to produce a deliverable.
Appendix B: How to refer to ATAG 2.0 from other documents
This section is informative.
There are two recommended ways to refer to the "Authoring Tool Accessibility
Guidelines 2.0" (and to W3C documents in general):
- References to a specific version of "Authoring Tool Accessibility
Guidelines 2.0." For example, use the "this version" URI to
refer to the current document: http://www.w3.org/TR/2007/WD-ATAG20-20070430/.
- References to the latest version of "Authoring Tool Accessibility
Guidelines 2.0." Use the "latest version" URI to refer to
the most recently published document in the series: http://www.w3.org/TR/ATAG20/.
In almost all cases, references (either by name or by link) should be to
a specific version of the document. W3C will make every effort to make this
document indefinitely available at its original address in its original form.
The top of this document includes the relevant catalog metadata for specific
references (including title, publication date, "this version" URI,
editors' names, and copyright information).
An XHTML 1.0 paragraph including a reference to this specific document
might be written:
<p>
<cite><a href="http://www.w3.org/TR/2007/REC-ATAG20-20070430/">
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Treviranus, J. Richards, eds.,
W3C Recommendation, 30 April 2007.
The <a href="http://www.w3.org/TR/ATAG20/">latest version</a> of this document is available at http://www.w3.org/TR/ATAG20/.</p>
For very general references to this document (where stability of content
and anchors is not required), it may be appropriate to refer to the latest
version of this document. Other sections of this document explain how to build a conformance
claim.
Appendix C: References
This section is informative.
For the latest version of any W3C specification
please consult the list of W3C Technical
Reports at http://www.w3.org/TR/. Some documents listed below may have
been superseded since the publication of this document.
Note: In this document, bracketed labels such as "[HTML4]" link
to the corresponding entries in this section. These labels are also identified
as references through markup.
- [ATAG10]
- "Authoring Tool Accessibility
Guidelines 1.0", J. Treviranus, C. McCathieNevile, I. Jacobs,
and J. Richards, eds., 3 February 2000. This W3C Recommendation is available
at http://www.w3.org/TR/2000/REC-ATAG10-20000203/.
- [ATAG20-TECHS]
- "Techniques
for Authoring Tool Accessibility 2.0", J. Treviranus, J. Richards,
C. McCathieNevile, and M. May, eds., 22 November 2004. The latest draft
of this W3C note is available at http://www.w3.org/TR/ATAG20-TECHS.
- [COMPONENTS]
- "Essential Components
of Web Accessibility", S. L. Henry, ed. This document is available
at http://www.w3.org/WAI/intro/components.
- [CSS2-ACCESS]
- "Accessibility
Features of CSS," I. Jacobs and J. Brewer, eds., 4 August 1999.
This W3C Note is available at http://www.w3.org/1999/08/NOTE-CSS-access-19990804.
The latest version of Accessibility
Features of CSS is available at http://www.w3.org/TR/CSS-access.
- [HTML4]
- "HTML
4.01 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs,
eds., 24 December 1999. This HTML 4.01 Recommendation is http://www.w3.org/TR/1999/REC-html401-19991224.
The latest version of HTML 4 is available
at http://www.w3.org/TR/html4.
- [IEC-4WD]
- IEC/4WD 61966-2-1: Colour Measurement and Management in Multimedia Systems and Equipment - Part 2.1: Default Colour Space - sRGB. May 5, 1998.
- [MATHML]
- "Mathematical Markup Language",
P. Ion and R. Miner, eds., 7 April 1998, revised 7 July 1999. This MathML
1.0 Recommendation is http://www.w3.org/1999/07/REC-MathML-19990707. The latest version of MathML 1.0 is available
at http://www.w3.org/TR/REC-MathML.
- [OFCOM]
- Guidance Notes, Section 2: Harm and offence Annex 1, "Ofcom Guidance
Note on Flashing Images and Regular Patterns in Television (Re-issued as
Ofcom Notes 25 July 2005)" available at http://www.ofcom.org.uk/tv/ifi/guidance/bguidance/guidance2.pdf)
- [PWD-USE-WEB]
- "How
People With Disabilities Use the Web", J. Brewer, ed., 4 January
2001. This document is available at http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/.
- [SMIL-ACCESS]
- "Accessibility
Features of SMIL," M.-R. Koivunen and I. Jacobs, eds., 21 September
1999. This W3C Note is available at available at http://www.w3.org/TR/SMIL-access.
- [sRGB]
- "A Standard Default Color Space for the Internet - sRGB," M. Stokes, M. Anderson, S. Chandrasekar, R. Motta, eds., Version 1.10, November 5, 1996. A copy of this paper is available at http://www.w3.org/Graphics/Color/sRGB.html.
- [SVG]
- "Scalable Vector Graphics (SVG)
1.0 Specification (Working Draft)", J. Ferraiolo, ed. The latest
version of the SVG specification is available at http://www.w3.org/TR/SVG.
- [SVG-ACCESS]
- "Accessibility of Scalable
Vector Graphics," C. McCathieNevile, M.-R. Koivunen, eds., 7
August 2000. This W3C Note is available at http://www.w3.org/TR/SVG-access.
- [WCAG10]
- "Web
Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden,
and I. Jacobs, eds., 5 May 1999. This WCAG 1.0 Recommendation
is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
- [WCAG10-TECHS]
- "Techniques for Web
Content Accessibility Guidelines 1.0," W. Chisholm, G. Vanderheiden,
and I. Jacobs, eds., 6 November 2000. This W3C Note is available at http://www.w3.org/TR/WCAG10-TECHS/.
- [WCAG20]
- "Web Content Accessibility
Guidelines 2.0 (Working Draft)", W. Chisholm, G. Vanderheiden,
and J. White, editors. The latest version of the Web Content Accessibility
Guidelines 2.0 is available at http://www.w3.org/TR/WCAG20/. Note:
This document is still a working draft.
- [WCAG20-TECHS-GENERAL]
- "General
Techniques for WCAG 2.0," J. Slatin, T. Croucher, eds. Note:
This document is still a working draft.
- [WCAG20-TECHS-CSS]
- "CSS Techniques
for WCAG 2.0," W. Chisholm, B. Gibson, eds. Note: This
document is still a working draft.
- [WCAG20-TECHS-HTML]
- "HTML Techniques
for WCAG 2.0," M. Cooper, ed. Note: This document is
still a working draft.
- [UAAG]
- "User Agent Accessibility Guidelines
1.0", I. Jacobs, J. Gunderson, E. Hansen, editors, 17 December
2002. This is a W3C Recommendation.
- [WCAG20-TECHS-SCRIPTING]
- "Client-side
Scripting Techniques for WCAG 2.0," M. May, B. Gibson, eds. Note:
This document is still a working draft.
- [WCAG20-UNDERSTANDING]
- "Understanding
WCAG 2.0," B. Caldwell, W. Chisholm, J. Slatin, G. Vanderheiden,
eds. Note: This document is still a working draft.
- [XAG]
- "XML Accessibility Guidelines",
D. Dardailler, S. B. Palmer, C. McCathieNevile, eds. 3 October 2002. This
is a Working Group Draft.
Appendix D: Acknowledgments
Participants active in the AUWG at the time of publication:
- Tim Boland (National Institute for Standards and Technology)
- Barry A. Feigenbaum (IBM)
- Greg Pisocky (Adobe)
- Jan Richards (Adaptive Technology Resource Centre, University of Toronto)
- Roberto Scano (IWA/HWG)
- Jutta Treviranus (WG Chair; Adaptive Technology Resource Centre, University
of Toronto)
Other previously active AUWG participants and other contributors to
WCAG 2.0
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler,
Geoff Deering, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday,
Marjolein Katsma, William Loughborough, Karen Mardahl, Charles McCathieNevile, Matt May,
Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob
Regan, Chris Ridpath, Gregory Rosmaita, Heather Swayne, Gregg Vanderheiden,
Carlos Velasco, and Jason White.
This document would not have been possible without the work of those
who contributed to ATAG 1.0.
This publication has been funded in part with Federal funds from the U.S.
Department of Education under contract number ED05CO0039. The content of
this publication does not necessarily reflect the views or policies of the
U.S. Department of Education, nor does mention of trade names, commercial
products, or organizations imply endorsement by the U.S. Government.
[Contents] [Techniques]
[Checklist]