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/.
W3C Public Draft of ATAG 2.0
This is a W3C Public Working Draft. This draft integrates changes made as a result of comments received on the 7 December 2006 Public Working Draft and also includes changes intended to keep the document harmonized with WCAG 2.0. Substantial changes include: (1) adopting the three priority level per guideline structure of WCAG 2.0, (2) clarifying whether guidelines apply to an authoring tool's own user interface (menus, etc.) or to the display of content being edited, and (3) allowing Web content accessibility standards other than WCAG (e.g., national standards) to be used within ATAG 2.0 conformance claims (Please note that the AUWG "highly recommends [WCAG] due to the quality of the document and the process under which it was developed").
The Working Group seeks feedback on the following points for this draft:
-
Are the Guidelines and Success Criteria clear?
- Are the Success Criteria implementable and testable?
- Does meeting the Success Criteria in Part A improve accessibility of the authoring tool?
- Does meeting the Success Criteria in Part B improve the likelihood that authors will produce more accessible content?
Comments on this working draft are due on or before 21 April 2008. Comments on the draft should be sent to public-atag2-comments@w3.org (Public Archive).
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 2.0 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.
ATAG 2.0 defines an "authoring tool" as any software, or collection of software components, that authors can use to create or modify
Web content for use by other people.
This definition can cover components such as :
- content management systems, courseware tools, content aggregators
- site management tools
- WYSIWYG editors, plain text editors (embedded and stand-alone)
- conversion tools, productivity software that can output Web content technologies (e.g., "Save as HTML")
- blogging tools, wikis, online forums, emailers that produce Web-content
- multimedia authoring tools
- scripting tools, widget development environment
- etc.
Note: Synchronous tools (e.g., chats, collaboration tools, whiteboards, etc.), especially those that archive as Web content, are considered authoring tools and can be made more accessible for both participants and users of the stored archives. While not all parts of ATAG 2.0 will usefully apply, some Techniques for Real-Time Content Production are available.
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
Two Parts
ATAG 2.0 is 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 to authors with disabilities. 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 components.
- Authoring tool must be operable - Authors with a wide range of abilities must be able to operate its user interface components.
- Authoring tool must be understandable - Authors with a wide range of abilities must be able to understand the user interface components 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
authoring tool and the author. This guideline specifies 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 practices, 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 Part B 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 success criteria 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 software, 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 particular Web content technologies that an authoring tool produces and is implemented using (if applicable).
The recommended reference for the Web Content Accessibility "Benchmark" is the
W3C Web Content Accessibility Guidelines (WCAG) 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
PART A:
Make the authoring tool user interface accessible
Conformance Notes for Part A:
PRINCIPLE
A.1: Authoring tool must facilitate access
by assistive technologies
Guideline A.1.1
[For the authoring tool user interface] Ensure that 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.
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
Applicability Note: This guideline does not apply to non-Web-based authoring tool user interfaces.
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.
Level A Success Criteria for Guideline A.1.2
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), this is 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 is 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).
Applicability Note: This guideline does not apply to Web-based authoring tool user interface functionality.
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 applications that adhere to those conventions easier to use.
Level A Success Criteria for Guideline A.1.3
- A.1.3.1 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following:
- (a) Input: Keyboard, mouse, etc. including non-interference with keyboard accessibility features of the platform (e.g., StickyKeys, SlowKeys, browser link navigation)
- (b) Focus
- (c) Selection, and
- (d) Product installation.
Level AA Success Criteria for Guideline A.1.3
- A.1.3.2 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following:
- (a) User interface design,
- (b) Keyboard
configuration, and
- (c) Documentation.
Level AAA Success Criteria for Guideline A.1.3
- (No level AAA success criteria for Guideline A.1.3)
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): Editing
views that render non-text
objects contained within the content being
edited can display any text
alternatives that are identifiable by the authoring tool. It is permissible for the authoring
tool to change editing views to display the text
alternatives (e.g., from WYSIWYG to instruction level).
- A.2.1.2 Non-text Objects (user
interface "chrome"): Non-text
objects in the "chrome" have text
alternatives that present equivalent information, except for the situations listed below. [WCAG 2.0]
- (a) Controls-Input: If a non-text object is a control or accepts user input, then it has a name that describes its purpose. [WCAG 2.0]
- (b) Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text object. [WCAG 2.0]
- (c) 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. [WCAG 2.0]
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 synchronized media.
[Techniques]
Rationale: People
who have difficulty accessing or interpreting synchronized media 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
Level AA Success Criteria for Guideline A.2.2
- A.2.2.4 Audio Description (user interface "chrome"): If prerecorded video is present in the user interface "chrome", then at least one of the following are true:
[WCAG 2.0]
- (a) Audio Track: all of the information in the video track is provided in the audio track, or
- (b) Audio Descriptions: audio descriptions are provided.
Level AAA Success Criteria for Guideline A.2.2
Guideline A.2.3
[For the authoring tool user interface] Ensure that the interface can be presented in different ways.
[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 Name, Role, Value (user
interface "chrome"): For all user interface components in the user interface "chrome", all of the following are true: [WCAG 2.0]
- (a) the name and role are available via the platform,
- (b) states, properties, and values that can be set by authors are available via the platform, and
- (c) notification of changes to these items is available via the platform.
- A.2.3.2 Info and Relationships (user
interface "chrome"): In the user interface "chrome", information, structure, and relationships conveyed through presentation is available via the platform or are available in text. [WCAG 2.0]
- A.2.3.3 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 is made available via the platform (e.g., if misspelled text is underlined, the fact that it is is misspelled is important).
- A.2.3.4 Access to Presentation Being Edited (content
displays): If an editing view (e.g., WYSIWYG) renders any of the following text presentation properties and those properties are editable by any editing view (e.g., instruction level), then the properties are made available via the platform:
- (a) font,
- (b) style (e.g., italic, bold),
- (c) color, and
- (d) size.
- A.2.3.5 Meaningful Sequence (user interface "chrome"): When the sequence in which user interface "chrome" components are presented affect their meaning, a correct reading sequence is available via the platform. [WCAG 2.0]
- A.2.3.6 Sensory Characteristics (user
interface "chrome"): Instructions provided for understanding and operating the user interface "chrome" do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound. [WCAG 2.0]
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.7 Access to Presentation Being Edited (content displays): Any text presentation properties (text size, positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG editing views ) and editable by any editing view are available via the platform.
Guideline A.2.4
[For the authoring tool user interface] Make it easier to see and hear the interface.
[Techniques]
Rationale: Some authors require 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 intended to be high contrast).
Level A Success Criteria for Guideline A.2.4
- A.2.4.1 Independence of Display (content
display): Editing
views that usually have their display characteristics set
by rendering the content being
edited (e.g., WYSIWYG editing views)allows the
authors' visual and audio display settings to override these characteristics without
affecting the content (e.g.,
markup, stylesheets, etc.) being edited.
- A.2.4.2 Use of Color (user interface "chrome", content display): Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. [WCAG 2.0]
- A.2.4.3 Audio Control (user
interface "chrome", content display): If any audio plays automatically for more than 3 seconds, at least one of the following is true:
- (a) Pause: authors can pause or stop the audio, or
- (b) Control: authors can set the audio volume to a different level from the system volume level. [WCAG 2.0]
- A.2.4.4 Visual Display (user interface "chrome", content display): If a visual display is provided, authors can configure the visual display settings (i.e., fonts, sizes,
colors, spacing, positioning, and contrast) by at least one of the following methods:
- (a) Platform Settings: an option to inherit the platform settings,
or
- (b) Tool Specific Settings: content display settings specific to the authoring tool.
- A.2.4.5 Audio Display (user interface "chrome", content display): If an audio display is provided, authors can configure the audio display settings (i.e., volume, speech voices,
voice speed, and voice emphasis) by at least one of the following methods:
- (a) Platform Settings: an option to inherit the platform settings, or
- (b) Tool Specific Settings: content display settings specific to the authoring tool.
Level AA Success Criteria for Guideline A.2.4
- A.2.4.6 Visual Configurability (user
interface "chrome", content display): If the visual display
settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least
comparable configuration ranges as the platform provides.
- A.2.4.7 Audio Configurability (user
interface "chrome", content display): If the audio display
settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least
comparable configuration ranges as the platform provides.
Level AAA Success Criteria for Guideline A.2.4
- A.2.4.8 Low or No Background Audio (user
interface "chrome"): Audio that contains speech in the foreground does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground speech, with the exception of occasional sound effects. Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech. [WCAG 2.0]
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.
PRINCIPLE
A.3: Authoring tool user interface must be operable
Guideline A.3.1
[For the authoring tool user interface] Ensure that 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.
Level A Success Criteria for Guideline A.3.1
- A.3.1.1 Keyboard (user interface "chrome", content display): Authors can, through keyboard input alone, 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. This means non-keyboard accessible mechanisms can remain available (e.g.,
providing resizing with mouse-"handles" and with a properties
dialog). [WCAG 2.0, UAAG 2.0]
- A.3.1.2 No Keyboard Trap (user interface "chrome", content display): If focus can be moved to a component with the keyboard, then at least one of the following is true:
- (a) standard keys: focus can be moved away from the component with the keyboard using standard navigation keys (i.e., unmodified arrow or tab keys), or
- (b) documented non-standard keys: focus can be moved away from the component with non-standard keys and the author is advised of the method. [WCAG 2.0]
- A.3.1.3 Available Keystrokes (user interface "chrome", content display): Authors can always determine the currently available
keystrokes (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). [UAAG 2.0]
- A.3.1.4 Standard Text Area Conventions (content
display): Editing
views that allow text entry 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 can use the keyboard to traverse forwards/backwards all of the components, including those in floating toolbars, panels, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab"). [UAAG 2.0]
Level AA Success Criteria for Guideline A.3.1
- A.3.1.6 Accelerator Keys (user interface "chrome"): If the authoring tool includes any of the following functions, authors can 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.
- A.3.1.7 Change Accelerator Keys (user interface "chrome"): Authors can modify key-plus-modifier-key (or single-key) combinations.
Level AAA Success Criteria for Guideline A.3.1
- A.3.1.8 Inter-group Navigation (user interface "chrome", content display): If logical groups of focusable components (e.g., toolbars, dialogs, labeled groups, panels) are present, authors can use the keyboard to navigate to a focusable component in the next and previous groups. [UAAG 2.0]
- A.3.1.9 Group Navigation (user interface "chrome", content display): If logical groups of focusable components are present, authors can use the keyboard to navigate to the first, last, next and previous focusable component within the current group. [UAAG 2.0]
Note 1: 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.
Note 2: 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.
Guideline A.3.2
[For the authoring tool user interface] Enable time-independent interaction.
[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.2
- A.3.2.1 Data Saved (user interface "chrome", content
display): If the authoring tool ends an authoring session due to a time limit (e.g., authenticated session expires), then the content being edited is saved. For Web-Based Authoring Tools, this applies to any content that has already been submitted to the application by the user agent.
- A.3.2.2 Timing Adjustable (user interface "chrome", content display): If the authoring tool is responsible for imposing a time limit on authoring sessions (e.g., to mediate collaborative
authoring), then authors can extend the time limit.
- A.3.2.3 Moving Targets (user interface "chrome"): If components that act as targets for authors' actions (e.g., are clickable, accept drag-and-drop actions) are capable of movement, then authors can stop that movement.
Level AA Success Criteria for Guideline A.3.2
- (No level AA success criteria for Guideline A.3.2)
Level AAA Success Criteria for Guideline A.3.2
- A.3.2.4 No Time Limits: The authoring tool does not impose time limits on authoring sessions.
Guideline A.3.3
[For the authoring tool user interface] Help authors 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.3
Level AA Success Criteria for Guideline A.3.3
- (No level AA success criteria for Guideline A.3.3)
Level AAA Success Criteria for Guideline A.3.3
Guideline A.3.4
[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.4
Level AA Success Criteria for Guideline A.3.4
- A.3.4.2 Navigate By Element Type (content
display): If an editing
view displays a structured
element set, authors can move the editing focus forward/backward to the next identical or closely related (e.g., in the case of headers) element.
- A.3.4.3 Navigate Tree Structures (content
display): If an editing
view displays a structured
element set, authors can, with a simple action, move
the editing focus from any element to
other elements in the set with any of the following
relationships (if they exist):
- (a) Parent: the element immediately
above,
- (b) Child: the first element immediately
below,
- (c) Previous Sibling: the element immediately
preceding at the same level, and
- (d) Next Sibling: the element immediately
following at the same level.
Level AAA Success Criteria for Guideline A.3.4
- (No level AAA success criteria for Guideline A.3.4)
Guideline
A.3.5 [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.
Level A Success Criteria for Guideline A.3.5
- (No level A success criteria for Guideline A.3.5)
Level AA Success Criteria for Guideline A.3.5
- A.3.5.1 Text Search (content
display): A text search function is provided that meets the following conditions:
- Search All Editable: can search any textual information (including
text content, text
alternatives for non-text
objects, metadata, markup) that is editable using the authoring tool.
- Bi-Directional: can search backwards and forwards. [UAAG 2.0]
- Case Sensitive: can search in both case sensitive and case insensitive modes. [UAAG 2.0]
- May Switch Views: permissible for the authoring tool to switch editing views to display the search results (e.g.,
from WYSIWYG to instruction level in order to display markup).
Level AAA Success Criteria for Guideline A.3.5
- (No level AAA success criteria for Guideline A.3.5)
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.
Guideline A.3.6
[For the authoring tool user interface] Manage 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.6
- (No level A success criteria for Guideline A.3.6)
Level AA Success Criteria for Guideline A.3.6
- A.3.6.1 Save Settings (user
interface "chrome"): Preference settings are stored for any of the following that the authoring tool controls
(i.e., not controlled by the platform):
Level AAA Success Criteria for Guideline A.3.6
- A.3.6.2 Multiple Sets (user
interface "chrome"): Choosing between multiple sets of preferences (e.g., personal profiles,
personal settings) are supported for any of the following that the authoring tool controls (i.e., not controlled by the platform):
- A.3.6.3 Options Wizard (user
interface "chrome"): Authors are provided with an accessibility option-setting "wizard" to configure options related to Part A.
Guideline A.3.7
[For the authoring tool user interface] Ensure that 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.
Level A Success Criteria for Guideline A.3.7
- A.3.7.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) is provided that meets the keyboard accessibility requirement (Guideline A.3.1) and
is documented in the help system.
- A.3.7.2 Preview (user interface "chrome", content display): If a preview is provided, then it meets at least one of the following:
- (a) Existing User Agent: the preview makes
use of an existing user
agent that is specified in the conformance
profile (e.g., opening the
content in a third-party browser or browser component),
- (b) Part A: the preview meets
all of the Level A guidelines in Part
A of these guidelines, or
- (c) UAAG: the preview conforms
to a version of the User Agent Accessibility Guidelines [UAAG].
Level AA Success Criteria for Guideline A.3.7
- (No level AA success criteria for Guideline A.3.7)
Level AAA Success Criteria for Guideline A.3.7
- (No level AAA success criteria for Guideline A.3.7)
Note: 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 this guideline.
PRINCIPLE
A.4: Authoring tool user interface must be understandable
Guideline A.4.1 Make text content readable and understandable. [Techniques]
Rationale: Some authors will benefit from support for understanding unusual words or abbreviations
Level A Success Criteria for Guideline A.4.1
- (No level A success criteria for Guideline A.4.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
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
Level AA Success Criteria for Guideline A.4.2
- A.4.2.4 Consistent Navigation (user
interface "chrome"): Navigational mechanisms that are repeated in multiple areas of the user interface "chrome" occur in the same relative order each time they are repeated, unless a change is initiated by the authors. [WCAG 2.0]
Level AAA Success Criteria for Guideline A.4.2
Guideline A.4.3 [For the
authoring tool user interface] Help users avoid and correct mistakes.
[Techniques]
Rationale: People who have difficulty making fine movements may be prone to making
unintended actions.
Level A Success Criteria for Guideline A.4.3
- A.4.3.1 Undo Content Changes (content
display): Authoring actions are either reversible by an "undo" function or include a warning
to authors that the action is irreversible. The authoring
tool may have certain committing actions (e.g., "save" function)
that reset the undo history.
- A.4.3.2 Undo Setting Changes (user
interface "chrome"): Actions
that modify authoring tool settings are either reversible or include a warning
to the author that the setting modification is irreversible.
- A.4.3.3 Error Identification: If an input error is detected, the component that is in error is identified and the error is described to authors in text. [WCAG 2.0]
- A.4.3.4 Labels or Instructions: Labels or instructions are provided when author input is required. [WCAG 2.0]
Level AA Success Criteria for Guideline A.4.3
- A.4.3.5 Redo (user
interface "chrome", content
display): Authors are able to immediately reverse the most recent undo(s) (i.e., a "redo" function).
- A.4.3.6 Error Prevention: If an input error is detected and suggestions for correction are known, then the suggestions are provided to authors, unless it would jeopardize security. [WCAG 2.0]
Level AAA Success Criteria for Guideline A.4.3
Note 1: Web-based authoring tool user interface functionality may rely on the "undo" function of the user
agent listed in the conformance
profile to perform the undo function for some editing actions
that do not involve server communication (e.g., typing in a
text area).
Note 2: It
is acceptable to collect text entry actions (e.g., typed words, a
series of backspaces) into a single reversible authoring action.
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 is either:
- (a) "A" Accessible: Web content and conforms to a minimum
level of Web content accessibility (although it is not necessary
for the documentation to be delivered on-line), or
- (b) Accessible Platform Format: not Web content and conforms 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 (other than documentation) that are specifically required
to meet Part
A of these guidelines (e.g.
keyboard shortcuts, text search, etc.) are 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
- (No level AAA success criteria for Guideline A.4.4)
PART
B: Support the production of accessible content
Conformance Notes for Part B:
- Referenced Technologies Only: While the production of accessible content is always recommended, conformance claims are only made in reference to the benchmarked Web content technologies identified in the conformance claim.
PRINCIPLE
B.1: Production of accessible content must be enabled
Guideline B.1.1 Support Web content technologies that enable the creation of content that is accessible.
[Techniques]
Rationale: Using Web content technologies
with published Web content accessibility benchmarks facilitates accessibility evaluation.
Level A Success Criteria for Guideline B.1.1
- B.1.1.1 Automatic Choice of "A" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "A" benchmarked technology.
- B.1.1.2 Author Choice of "A" Technologies: If the authoring tool provides authors with technology options, level "A" benchmarked technology options are listed with at least as much prominence as any other options.
Level AA Success Criteria for Guideline B.1.1
- B.1.1.3 Automatic Choice of "AA" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "AA" benchmarked technology.
- B.1.1.4 Author Choice of "AA" Technologies: If the authoring tool provides authors with technology options, level "AA" benchmarked technology options are listed with at least as much prominence as any other options.
Level AAA Success Criteria for Guideline B.1.1
- B.1.1.5 Automatic Choice of "AAA" Technologies: If the authoring tool automatically selects Web content technologies automatically, then the selection is a level "AAA" benchmarked technology.
- B.1.1.6 Author Choice of "AAA" Technologies: If the authoring tool provides authors with technology options, level "AAA" benchmarked technology options are listed with at least as much prominence as any other options.
Applicability Note: This guideline only applies when benchmarked technologies are available for authoring the particular type of content required (e.g., text, images, synchronized media).
Guideline B.1.2
Ensure that the authoring tool preserves accessibility
information.
[Techniques]
Rationale: Accessibility
information is critical to maintaining comparable levels of accessibility
across transformations and conversions.
Level A Success Criteria for Guideline B.1.2
- B.1.2.1 Transformation or Conversion: If the authoring tool performs transformations or conversions,
then at least one of the following is true:
- (a) Preserve in Output: any accessibility
information in the pre-transformation/conversion content is preserved and available for end
users in the resulting content;
or
- (b) Preserve Input and Notify: a copy of the pre-transformation/conversion content is retained (e.g., as a "comment", by saving a backup
copy) and the authors are notified of the location.
Level AA Success Criteria for Guideline B.1.2
- B.1.2.2 Notification Prior to Deletion: If the authoring tool automatically deletes any author-generated content for any reason, then at least one of the following is true:
- (a) Not Accessibility Information: the authoring tool can detect that the content is not accessibility
information; or
- (b) Notification Option: authors have the option to receive notification before deletion.
Level AAA Success Criteria for Guideline B.1.2
- (No level AAA success criteria for Guideline B.1.2)
Guideline B.1.3
Ensure that automatically generated content is accessible.
[Techniques]
Rationale: Authoring
tools that automatically generate content that is not accessible impose additional repair tasks on authors.
Related: If accessibility
information is required from authors during
the automatic generation process, see Guideline
B.2.1. If templates or other pre-authored content are involved, see Guideline B.2.5.
Level A Success Criteria for Guideline B.1.3
Level AA Success Criteria for Guideline B.1.3
Level AAA Success Criteria for Guideline B.1.3
Applicability Note 1: This guidelines does apply to any accessibility problems that informed authors have specifically allowed (e.g., by setting less strict preferences) (see Guideline B.3.3 for more on informing the author).
Applicability Note 2: This guideline does not apply when authors have caused the accessibility problem(s) (e.g.,
by ignoring prompts for accessibility information, providing faulty information, etc.).
PRINCIPLE B.2:
Authors must be supported in the production of
accessible content
Guideline B.2.1 Prompt authors to
create accessible content.
[Techniques]
Rationale: By guiding the authors from the outset towards the creation and maintenance of accessible content, accessibility problems are mitigated and less repair and retrofit effort is required.
Level A Success Criteria for Guideline B.2.1
Level AA Success Criteria for Guideline B.2.1
- B.2.1.3 Prompt "AA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet the level "AA" Web content accessibility
benchmarks.
- B.2.1.4 Warn "AA" Accessible: If an authoring action or instruction will always lead to the creation
of content that cannot be made to meet the level "AA" Web content accessibility
benchmarks other than by making an alternative version, then
a warning is displayed.
Level AAA Success Criteria for Guideline B.2.1
- B.2.1.5 Prompt "AAA" Accessible: If authors are prompted for any information as content is being added or updated, then the tool also prominently prompts for accessibility information required for that content to meet the level "AAA" Web
content accessibility benchmarks.
- B.2.1.6 Warn "AAA" Accessible: If an authoring action or
instruction will always lead to the creation of content that cannot be made to meet the
level "AAA" Web content accessibility
benchmarks other than by making an alternative version, then
a warning is displayed.
Guideline B.2.2 Assist authors in checking for accessibility problems.
[Techniques]
Rationale: Checking as an integrated function of the authoring tool helps make authors aware of accessibility problems during the authoring process, so they can be immediately addressed.
Level A Success Criteria for Guideline B.2.2
- B.2.2.1 Check "A" Accessibility: An individual check is associated with each level
"A" Web
content accessibility benchmark.
- B.2.2.2 Availability: Checking is available to authors prior
to the end
of the authoring session.
- B.2.2.3 Identify Range: The appropriate range (e.g., element, group of elements, entire file, etc.) for each potential accessibility
problem is identified. Excessively general checks (e.g., "does the page meet
all of the requirements?") are not acceptable.
- B.2.2.4 Help Authors Decide: For any checks that require author judgment to determine whether
a potential accessibility
problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided
to help authors to
decide.
Level AA Success Criteria for Guideline B.2.2
- B.2.2.5 Check "AA" Accessibility: An individual check is associated with each level
"AA" Web content accessibility benchmark.
- B.2.2.6 View Status: If the authoring tool records accessibility problems
found during checking, then a list of any accessibility problems is available to authors prior to the end of the authoring session.
- B.2.2.7 Save Status for Repair: If the authoring tool records accessibility problems found during checking, then authors have the option to save the list to facilitate interoperability between checking and repair.
- B.2.2.8 Metadata for Discovery: If the authoring tool records accessibility status, then authors have the option to associate this status with the content as metadata to facilitate resource discovery by end users.
Level AAA Success Criteria for Guideline B.2.2
Note: While automated
checking or more advanced implementations of semi-automated
checking may improve the authoring experience, these are not
required to meet the success criteria for this guideline.
Applicability Note: This guideline does not apply if the authoring tool controls the authoring process to an extent that it is not possible for authors to introduce accessibility problems.
Guideline B.2.3
Assist authors in repairing accessibility problems.
[Techniques]
Rationale: Repair as an integral part of the authoring process greatly enhances the utility of checking and increases the likelihood that accessibility
problems will be properly addressed.
Level A Success Criteria for Guideline B.2.3
Level AA Success Criteria for Guideline B.2.3
Level AAA Success Criteria for Guideline B.2.3
Note: While automated
repairing or more advanced implementations of semi-automated
repairing may improve the authoring experience, these are not
required to meet the success criteria for this guideline.
Applicability Note: This guideline does not apply if the authoring
tool controls the authoring process to an extent that it
is not possible for authors to introduce accessibility problems.
Guideline
B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects.
[Techniques]
Rationale: Improperly
generated equivalent alternatives can create accessibility problems
and interfere with accessibility checking.
Level A Success Criteria for Guideline B.2.4
Level AA Success Criteria for Guideline B.2.4
- B.2.4.3 Acceptable Sources: Authoring tools only supply equivalent alternatives from the following sources:
- (a) Author-Entered: equivalent
alternatives previously entered by authors for
the same non-text
object (e.g., by the same author, or another author on
a collaborative system),
- (b) From Object Database: equivalent
alternatives stored with the non-text
object in an object database (or equivalent), or
- (c) Null when Appropriate: null equivalent
alternatives for non-text
objects that the authoring tool can detect are only used for visual formatting.
Level AAA Success Criteria for Guideline B.2.4
- B.2.4.4 Save for Reuse: Authors can store, for future reuse, both of the following author-assigned equivalent
alternatives (as applicable):