This specification provides guidelines for designing web content authoring
tools that are both (1) more accessible to authors with disabilities and (2) designed to enable,
support, and promote the production of more accessible web content by all authors.
The "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0)
is part of a series of accessibility guidelines published by the
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/.
W3C Public Working Draft of ATAG 2.0
This is the W3C Last Call Working Draft of 10 April 2012. This draft integrates changes made as a result of comments received on the 21 July 2011 Working Draft, the 26 April 2011 Working Draft and the 8 July 2010 Last Call Working Draft. The Authoring Tool Accessibility Guidelines Working Group (AUWG) has refined ATAG 2.0 with the contributions of public commenters. Changes in this draft:
Publication as a Last Call Working Draft indicates that the Authoring Tool
Accessibility Guidelines Working Group (AUWG) believes it has addressed all
substantive issues and that the document is stable. The first public Working
Draft of ATAG 2.0 was published 14 March 2003. Since then, the AUWG has published nine Working Drafts and one previous Last Call Working Draft, addressed hundreds of issues and developed implementation support information for the guidelines. See How WAI Develops Accessibility
Guidelines through the W3C Process for more background on document maturity
Changes in this draft include:
- Conformance - added a conformance note to clarify unrecognized content is exempt from success criteria that require semantics when the semantic data is missing (e.g., text that describes an image is only considered to be a text alternative when this role is encoded within markup).
- Device Independence - added a note to A.3.1.1 Keyboard Access to clarify that this success criterion applies to any keyboard interface, and was not restricted to the presence of a hardware keyboard.
- Preview Conformance - clarified that A.3.7.1 Preview (Minimum) (b) conforms to UAAG 1.0, instead of UAAG.
- Accessibility Feature Documentation - added clarification and conditions to A.4.2.1 Describe Accessibility Features and A.4.2.2 Document All Features to enhance the ability to test if the feature qualifies as an accessibility feature.
- Copy-Paste functions - added success criterion B.1.2.2 Copy-Paste Inside Authoring Tool that copy-paste functions within the tool preserve accessibility information.
- Accessible Technologies - Removed B.2.2.3 Technology Decision Support after feedback that it would be burdensome to the user and added B.4.1.3 Feature Availability Information to inform the user if technology options within the authoring tool did not produce accessible content.
- Conformance Requirements - added Success Criteria Satisfaction for specialized authoring tools that may only implement a subset of ATAG appropriate to their limited functionality. Added conditional clauses to success criteria to clarify when conformance is not applicable.
- Definitions - added the definition of accessible content; added a note and Appendix to Implementing ATAG 2.0 on accessibility information; added reversible authoring action; clarified author generated content; clarified content transformations; and expanded the definition of keyboard interface to clearly include virtual keyboards.
The working group would particularly appreciate feedback on the following issues:
- Does the new Partial Conformance (Process Components) option provide reasonable coverage with respect to tools that perform only a small role in content authoring?
- Does the new Partial Conformance (Platform Limitations) option provide a reasonable mechanism for situations in which platform shortcomings prevent full conformance by authoring tools on the platform?
- Does the new formulation of guideline B.1.2 (Ensure accessibility information is preserved) provide reasonable guidance when authoring tools transform content or copy/paste content?
Comments on this working draft are due on or before 5 June
2012. Comments on the draft should be sent to email@example.com (Public
The Authoring Tool Accessibility Guidelines Working Group (AUWG) intends to publish ATAG 2.0 as a W3C Recommendation. Until that time Authoring Tool Accessibility Guidelines (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
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.
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.
This is a Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) version
2.0. This document includes recommendations for assisting authoring tool developers to make their authoring tools more accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, motor difficulties, speech difficulties, and others.
Accessibility, from an authoring tool perspective, includes addressing the needs of two overlapping user groups with disabilities:
It is important to note that, while the requirements for meeting these two sets of user needs are separated for clarity within the guidelines, the accelerating trend toward user-produced content means that, in reality, they are deeply inter-connected. For example, when a user participates in an online forum, they frequently author content that is then incorporated with other content authored by other users. Accessibility problems in either the authoring user interface or the content produced by the other forum users would reduce the overall accessibility of the forum.
- The term "authoring tools" has a specific definition in ATAG 2.0. The definition, which includes several normative notes, appears in the Glossary.
- The term "accessible content (WCAG)" (and related terms, such as "accessible template (WCAG)") is used by ATAG 2.0 to refer to "content that would conform to WCAG 2.0, at either Level A, AA, or AAA, assuming that any web content technologies relied upon to satisfy the WCAG 2.0 success criteria are accessibility supported. The definition of the term reflects the WCAG 2.0 note that even content that conforms to the highest level of WCAG 2.0 (i.e., Level AAA) may not be "accessible to individuals with all types, degrees, or combinations of disability". For more information, see "Relationship to the Web Content Accessibility Guidelines (WCAG) 2.0".
- ATAG 2.0 does not include standard usability recommendations, except where they have a significantly greater impact on people
with disabilities than on other people.
- Authoring tools are just one aspect of web accessibility. For an overview of the different components of web accessibility and how they work together see:
ATAG 2.0 Layers of Guidance
The individuals and organizations that may use ATAG 2.0 vary widely and include authoring tool developers, authoring tool users (authors), authoring tool purchasers, and policy makers. In order to meet the varying needs of this audience, several layers of guidance are provided:
- Parts: ATAG 2.0 is divided into two parts, each reflecting a key aspect of accessibility with respect to authoring tools. Part A relates to the accessibility of authoring tool user interfaces to authors with disabilities. Part B relates to support by authoring tools for the creation, by any author (not just those with disabilities), of web content that is more accessible to end
users with disabilities. Both parts include normative "Conformance Applicability Notes" that apply to all of the success criteria within that part (see Part A Conformance Applicability Notes and Part B Conformance Applicability Notes).
- Principles: Under each part are several high-level principles that organize the guidelines.
- Guidelines: Under the principles are guidelines. The guidelines provide the basic goals that authoring tool developers should work toward in order to make authoring tools more accessible to both authors and end
users of web content with different disabilities. The guidelines are not testable, but provide the framework and overall objectives to help authoring tool developers understand the success criteria. Each guideline includes a brief rationale for why the guideline was included.
- Success Criteria: For each guideline, testable success criteria are provided to allow ATAG 2.0 to be used where requirements and conformance testing are necessary, such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, multiple levels of full and partial conformance are defined (see Levels of Conformance).
- Implementing ATAG 2.0 document: The Implementing ATAG 2.0 document provides additional non-normative information for each success criterion, including a description of the intent of the success criterion, examples and links to related resources.
Levels of Conformance
In order to ensure that the process of using ATAG 2.0 and WCAG 2.0 together in the development of authoring tools is as simple as possible, ATAG 2.0 shares WCAG 2.0's three level conformance model: Level A (lowest), AA (middle), AAA (highest). For more information, see Understanding Levels of Conformance.
Integration of Accessibility Features
When implementing ATAG 2.0, authoring tool developers should carefully integrate features that support more accessible authoring into the same "look-and-feel" as other features of the authoring tool. Close integration has the potential to:
- produce a more seamless product;
- leverage the existing knowledge and skills of authors;
- make authors more receptive to new accessibility-related authoring requirements; and
- reduce the likelihood of author confusion.
The success criteria and the conformance applicability notes in this section are normative.
PART A: Make the authoring tool user interface accessible
- Scope of "authoring tool user interface": The Part A success criteria apply to all aspects of the authoring tool user interface that are concerned with producing the "included" web content technologies. This includes views of the web content being edited and features that are independent of the content being edited (e.g., menus, button bars, status bars, user preferences, documentation).
- Reflected content accessibility problems: The authoring tool is responsible for ensuring that editing-views display the web content being edited in a way that is more accessible to authors with disabilities (e.g., ensuring that text alternatives in the content can be programmatically determined). However, where an authoring tool user interface accessibility problem is caused directly by the content being edited (e.g., if an image in the content lacks a text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.
- Developer control: The Part A success criteria only apply to the authoring tool user interface as it is provided by the developer. They do not apply to any subsequent modifications by parties other than the authoring tool developer (e.g., user modifications of default settings, third-party plug-ins).
- User agent features: Web-based authoring tools may rely on user agent features (e.g., keyboard navigation, find functions, display preferences, undo features) to satisfy success criteria. Conformance claims are optional, but any claim that is made must record the user agent(s).
- Accessibility of features provided to meet Part A: The Part
A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part A (e.g., documentation, search functions). The only exemption is for preview features,
as long as they meet the relevant success criteria in Guideline A.3.7. Previews are treated differently than editing-views because all authors, including those with disabilities, benefit when preview features accurately reflect the functionality of user
agents that are actually in use by end users.
- Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g., text that describes an image is only considered to be a text alternative when this role is encoded within markup).
PRINCIPLE A.1: Authoring tool user interfaces must follow applicable accessibility guidelines
Guideline A.1.1: (For the authoring tool user interface) Ensure that web-based functionality is accessible.
Rationale: When authoring tools (or parts of authoring tools) are web-based, conforming to WCAG 2.0 will facilitate access by all authors, including those using assistive technologies.
A.1.1.1 Web-Based Accessible (WCAG):
If the authoring tool contains web-based user interfaces, then those web-based user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Guideline A.1.2: (For the authoring tool user interface) Ensure that non-web-based functionality is accessible.
Rationale: When authoring tools (or parts of authoring tools) are non-web-based, following existing platform accessibility guidelines and implementing communication with platform accessibility services facilitates access by all authors, including those using assistive technologies.
PRINCIPLE A.2: Editing-views must be perceivable
Guideline A.2.1: (For the authoring tool user interface) Make alternative content available to authors.
Rationale: Some authors require access to alternative content in order to interact with the web content that they are editing.
Guideline A.2.2: (For the authoring tool user interface) Editing-view presentation can be programmatically determined.
Rationale: Some authors need access to details about the editing-view presentation, via their assistive technology, when that presentation is used to convey status messages (e.g., underlining misspelled words) or provide information about how the end user will experience the web content being edited.
A.2.2.1 Editing-View Status Indicators:
If an editing-view adds status indicators to the content being edited, then the status messages being indicated can be programmatically determined. (Level A)
- Note: Status indicators may indicate errors (e.g., spelling errors), tracked changes, hidden elements, or other information.
PRINCIPLE A.3: Editing-views must be operable
Guideline A.3.1: (For the authoring tool user interface) Provide keyboard access to authoring features. [Implementing A.3.1]
Rationale: Some authors with
limited mobility or visual disabilities are not able to use a mouse and instead require keyboard interface access to all of the functionality of the authoring tool.
A.3.1.1 Keyboard Access (Minimum):
All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
- Note 1: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard.
- Note 2: The path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle.
- Note 3: This success criterion does not forbid and should not discourage other input methods (e.g., mouse, touch) in addition to keyboard operation.
A.3.1.2 No Keyboard Traps:
If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away. (Level A)
A.3.1.4 Keyboard Access (Enhanced):
All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)
A.3.1.5 Customize Keyboard Access:
If the authoring tool includes keyboard commands, then those keyboard commands can be customized. (Level AAA)
A.3.1.6 Present Keyboard Commands:
If the authoring tool includes keyboard commands,
then the authoring tool provides a way for authors
to determine the keyboard commands associated with authoring tool user interface components
. (Level AAA)
Guideline A.3.2: (For the authoring tool user interface) Provide authors with enough time.
Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or that require fast reaction speeds, such as clicking on a moving target.
A.3.2.1 Auto-Save (Minimum):
If the authoring tool includes authoring session time limits, then the authoring tool can be set to automatically save web content edits made using the authoring tool before the session time limits are reached. (Level A)
A.3.2.2 Timing Adjustable:
If a time limit is set by the authoring tool, then at least one of the following is true: (Level A)
- (a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or
- (b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- (c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g., "press the space bar"), and authors are allowed to extend the time limit at least ten times; or
- (d) Real-time Exception: The time limit is a required part of a real-time event (e.g., a collaborative authoring system), and no alternative to the time limit is possible; or
- (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- (f) 20 Hour Exception: The time limit is longer than 20 hours.
A.3.2.3 Static Input Components:
If authoring tool user interface components accept input and move, then authors can pause the movement. (Level A)
A.3.2.4 Content Edits Saved (Extended):
The authoring tool can be set to automatically save web content edits made using the authoring tool. (Level AAA)
Guideline A.3.3: (For the authoring tool user interface) Help authors avoid flashing that could cause seizures.
Rationale: Flashing can cause seizures in authors with photosensitive seizure disorder.
A.3.3.1 Static View Option:
If the authoring tool contains editing-views that render visual time-based content, then those editing-views can be paused and can be set to not play automatically. (Level A)
Guideline A.3.4: (For the authoring tool user interface) Enhance navigation and editing via content structure.
Rationale: Some authors who have difficulty typing or operating the mouse benefit when authoring tools make use of the structure present in web content to simplify navigating and editing the content.
A.3.4.1 Navigate By Structure:
If editing-views expose the markup elements in the web content being edited, then the markup elements (e.g., source code, content renderings) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA)
A.3.4.2 Navigate by Programmatic Relationships:
If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. (Level AAA)
- Note: Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships.
Guideline A.3.5: (For the authoring tool user interface) Provide text search of the content.
Rationale: Some authors who have difficulty typing or operating the mouse benefit from the ability to use text search to navigate to arbitrary points within the web content being edited.
A.3.5.1 Text Search:
If the authoring tool provides an editing-view of text-based content, then the editing-view enables text search, such that all of the following are true: (Level AA)
- (a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
- (b) Match: Matching results can be made visible to authors and given focus; and
- (c) No Match: Authors are informed when no results are found; and
- (d) Two-way: The search can be made forwards or backwards.
Guideline A.3.6: (For the authoring tool user interface) Manage preference settings.
Rationale: Some authors need to set their own display settings in a way that differs from the presentation that they want to define for the published web content. Providing the ability to save and reload sets of keyboard and display preference settings benefits authors who have needs that differ over time (e.g., due to fatigue).
Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents.
Rationale: Preview features are provided by many authoring tools because the workflow of authors often includes periodically checking how user agents will display the web content to end users. Authors with disabilities need the same opportunity to check their work.
A.3.7.1 Preview (Minimum):
If a preview is provided, then at least one of the following is true: (Level A)
- (a) In-Market User Agent: The preview renders content using a user agent that is in-market; or
- (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines 1.0 Level A [UAAG].
A.3.7.2 Preview (Enhanced):
If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA)
PRINCIPLE A.4: Editing-views must be understandable
Guideline A.4.1: (For the authoring tool user interface) Help authors avoid and correct mistakes.
Rationale: Some authors with disabilities may be more susceptible to input errors due to factors such as difficulty making fine movements and speech recognition system errors.
Guideline A.4.2: (For the authoring tool user interface) Document the user interface including all accessibility features.
Rationale: Some authors may not be able to understand or operate the authoring tool user interface without documentation.
A.4.2.1 Describe Accessibility Features:
For each authoring tool feature that is used to meet Part A of ATAG 2.0, at least one of the following is true: (Level A)
- (a) Described in the documentation: Use of the feature is explained in the authoring tool's documentation; or
- (b) Described in the interface: Use of the feature is explained in the authoring tool user interface; or
- (c) Platform service: The feature is a service provided by an underlying platform; or
- (d) Not used by authors: The feature is not used directly by authors (e.g., passing information to a platform accessibility service).
A.4.2.2 Document All Features:
For each authoring tool feature, at least one of the following is true: (Level AA)
- (a) Described in the documentation: Use of the feature is explained in the authoring tool's documentation; or
- (b) Described in the interface: Use of the feature is explained in the authoring tool user interface; or
- (c) Platform service: The feature is a service provided by an underlying platform; or
- (d) Not used by authors: The feature is not used directly by authors (e.g., passing information to a platform accessibility service).
PART B: Support the production of accessible content
Part B Conformance Applicability Notes:
- Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
- Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g., third-party plug-ins, user-defined templates, user modifications of default settings).
- Applicability after the end of an authoring session: Authoring tools are responsible for the web content accessibility (WCAG) of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author causes, whether it is author-generated or automatically-generated by another system that the author has specified (e.g., a third-party feed).
- Authoring systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in any conformance claim) can be used in conjunction to meet the requirements of Part B (e.g., an authoring tool could make use of a third-party software accessibility checking tool).
- Accessibility of features provided to meet Part B: The Part
A success criteria apply to the entire authoring tool user interface, including any features that must be present to meet the success criteria in Part B (e.g., checking tools, repair tools, tutorials, documentation).
- Multiple authoring roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g., a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular authoring role. Accessible content support features should be made available to any authoring role where it would be useful.
- Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria do not apply when these semantics are missing (e.g., text that describes an image is only considered to be a text alternative when this role is encoded within markup).
PRINCIPLE B.1: Fully automatic processes must produce accessible content
Guideline B.1.1: Ensure automatically specified content is accessible. [Implementing B.1.1]
Rationale: If authoring tools automatically specify web content with accessibility problems (WCAG), then additional repair tasks are imposed on authors.
B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG):
If the authoring tool provides the functionality for automatically generating web content after the end of an authoring session, authors can specify that the content be accessible web content (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG):
If the authoring tool
provides the functionality for automatically generating web content
during an authoring session
, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
- (a) Accessible: The content is accessible web content (WCAG) without author input; or
- (b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or
- (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or
- (d) Checking Suggested: After the automatic generation process, the authoring tool prompts authors to perform accessibility checking.
Guideline B.1.2: Ensure accessibility information is preserved. [Implementing B.1.2]
Rationale: Accessibility information (WCAG) is critical to maintaining comparable levels of web content accessibility (WCAG) between the input and output of web content transformations.
B.1.2.1 Restructuring and Recoding Transformations (WCAG):
If the authoring tool provides restructuring transformations or re-coding transformations, and if equivalent mechanisms exist in the web content technology of the output, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
- (a) Preserve: Accessibility information (WCAG) is preserved in the output; or
- (b) Warning: Authors have the default option to be warned that accessibility information (WCAG) may be lost (e.g., when saving a vector graphic into a raster image format); or
- (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or
- (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking.
B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG):
If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
PRINCIPLE B.2: Authors must be supported in producing accessible content
Guideline B.2.1: Ensure accessible content production is possible.
Rationale: To support accessible web content (WCAG) production, at minimum, it must be possible to produce web content that conforms with WCAG 2.0 using the authoring tool.
B.2.1.1 Accessible Content Possible (WCAG):
If the authoring tool places restrictions on the web content that authors can specify, then those restrictions do not prevent WCAG 2.0 success criteria from being met. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Guideline B.2.2: Guide authors to produce accessible content.
Rationale: By guiding authors from the outset toward the creation and maintenance of accessible web content (WCAG), web content accessibility problems (WCAG) are mitigated and less repair effort is required.
B.2.2.1 Accessible Option Prominence (WCAG):
If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g., styling text), then options that will result in accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
B.2.2.2 Setting Accessibility Properties (WCAG):
If the authoring tool provides mechanisms to set web content properties (e.g., attribute values), then mechanisms are also provided to set web content properties related to accessibility information (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Guideline B.2.3: Assist authors with managing alternative content for non-text content.
Rationale: Improperly generated alternative content can create web content accessibility problems (WCAG) and interfere with accessibility checking.
See Also: This guideline applies when non-text content is specified by authors (e.g., inserting an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.1.
B.2.3.1 Alternative Content is Editable (WCAG):
If the authoring tool provides functionality for adding non-text content, then authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
B.2.3.2 Conditions on Automated Suggestions:
If the authoring tool automatically suggests text alternatives for non-text content during the authoring session, then the text alternatives may only be suggested under the following conditions: (Level A)
- (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested text alternatives prior to insertion; and
- (b) Relevant Sources: The suggested text alternatives are only derived from sources designed to fulfill the same purpose (e.g., suggesting the value of an image's "description" metadata field as a long description).
B.2.3.3 Let User Agents Repair:
If the authoring tool provides automatic repair of text alternatives for non-text content after the end of an authoring session, then the authoring tool avoids using text values that would also be available to user agents. (Level A)
- Note: Examples of text values that are also available to user agents, and should be avoided, include the filename, the file format, and generic phrases (e.g. "image").
Guideline B.2.4: Assist authors with accessible templates.
Rationale: Providing accessible templates (WCAG) can have several benefits, including: immediately improving the accessibility of the web content (WCAG) of being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG).
B.2.4.1 Accessible Template Options (WCAG):
If the authoring tool provides templates, then there are accessible template (WCAG) options for a range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
B.2.4.2 Identify Template Accessibility (Minimum):
If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)
- Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.
B.2.4.3 Author-Created Templates:
If the authoring tool includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA)
- Note: The distinction can involve providing information for the accessible templates (WCAG), the non-accessible templates or both.
Guideline B.2.5: Assist authors with accessible pre-authored content. [Implementing B.2.5]
Rationale: Providing accessible (WCAG) pre-authored content (e.g., clip art, synchronized media, widgets) can have several benefits, including: immediately improving the accessibility of web content (WCAG) being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG).
B.2.5.1 Pre-Authored Content Selection Mechanism:
If authors are provided with a selection mechanism for pre-authored content other than templates (e.g., clip art gallery, widget repository, design themes), then both of the following are true: (Level AA)
B.2.5.2 Pre-Authored Content Accessibility Status:
If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AAA)
PRINCIPLE B.3: Authors must be supported in improving the accessibility of existing content
Guideline B.3.1: Assist authors in checking for accessibility problems. [Implementing B.3.1]
Rationale: When accessibility checking is an integrated function of the authoring tool, it helps make authors aware of web content accessibility problems (WCAG) during the authoring process, so they can be immediately addressed.
B.3.1.1 Checking Assistance (WCAG):
If the authoring tool provides authors with the ability to add or modify web content in such a way that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion is provided (e.g., an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
Guideline B.3.2: Assist authors in repairing accessibility problems. [Implementing B.2.3]
Rationale: When repair as an integral part of the authoring process, it greatly enhances the utility of checking and increases the likelihood that web content accessibility problems (WCAG) will be properly addressed.
B.3.2.1 Repair Assistance (WCAG):
If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
PRINCIPLE B.4: Authoring tools must promote and integrate their accessibility features
Guideline B.4.1: Ensure the availability of features that support the production of accessible content.
Rationale: The accessible content support features will be more likely to be used, if they are turned on and are afforded reasonable prominence within the authoring tool user interface.
Guideline B.4.2: Ensure that documentation promotes the production of accessible content.
Rationale: Some authors need support in determining how to use accessible content production features (e.g. how to respond to prompts for text alternatives, how to use accessibility checking tools). Demonstrating accessible authoring as routine practice, or at least not demonstrating inaccessible practices, will help to encourage acceptance of accessibility by some authors.
Conformance means that the authoring tool satisfies the applicable success criteria defined in the
This conformance section describes conformance and lists the conformance requirements.
Success Criteria Satisfaction
The first step in determining ATAG 2.0 conformance is to assess whether the Success Criteria have been satisfied. The potential answers are:
- Not Applicable: The ATAG 2.0 definition of authoring tool is inclusive and, as such, it covers software with a wide range of capabilities and contexts of operation. In order to take into account authoring tools with limited feature sets (e.g., a photo editor, a CSS editor, a status update field in a social networking application), many of the ATAG 2.0 success criteria are conditional, applying only to authoring tools with the given features(s). If a conformance claim is made, an explanation of why the success criterion is not applicable is required.
- Yes: In the case of some success criteria, this will include a Level (A, AA, or AAA) with reference to WCAG 2.0. If a conformance claim is made, an explanation is optional, but strongly recommended.
- No: If a conformance claim is made, an explanation is optional, but strongly recommended.
to the Web Content Accessibility Guidelines (WCAG) 2.0
At the time of publishing, WCAG 2.0 [WCAG20] is the current W3C Recommendation regarding web content accessibility. For this reason, ATAG 2.0 refers to WCAG 2.0 when setting requirements for (1) the accessibility of web-based authoring tool user interfaces (in Part A) and (2) how authors should be enabled, supported, and guided toward producing web content that is more accessible to end users with disabilities (in Part B).
In particular, ATAG 2.0 refers to WCAG 2.0 within its definition of the term "accessible content" (and related terms, such as "accessible template"). The definition of "accessible content" is content that would conform to WCAG 2.0, at either Level A, AA, or AAA, under the assumption that any web content technologies that are relied upon to satisfy the WCAG 2.0 success criteria are accessibility supported. The phrase "at either Level A, AA, or AAA" takes into account that the definition of "accessible content" can differ depending on the context of use (e.g. in a Level A success criterion of ATAG 2.0 versus in a Level AAA success criterion). The definition also includes two notes:
- The first is "[i]f accessibility support for the relied upon technologies is lacking, then the content will not conform to WCAG 2.0 and one or more groups of end-users with disabilities will likely experience difficulty accessing the content."
- The second is "[c]onformance to WCAG 2.0, even at the highest level (i.e., Level AAA), still may not make content 'accessible to individuals with all types, degrees, or combinations of disability'." In order to highlight success criteria or defined terms in ATAG 2.0 that depend on WCAG 2.0, they are marked with the parenthetical: "(WCAG)".
Note on "accessibility-supported ways of using technologies":
Part of conformance to WCAG 2.0 is the requirement that "only accessibility-supported ways of using technologies are relied upon to satisfy the WCAG 2.0 success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported." In broad terms, WCAG 2.0 considers a web content technology to be "accessibility supported" when (1) the way that the web content technology is used is supported by users' assistive
technology and (2) the web content technology has accessibility-supported user
agents that are available to end users.
This concept is not easily extended to authoring tools because many authoring tools can be installed and used in a variety of environments with differing availabilities for assistive
technologies and user
agents (e.g., private intranets versus public websites, monolingual sites versus multilingual sites). Therefore:
ATAG 2.0 does not include the accessibility-supported requirement. As a result, ATAG 2.0 success criteria do not refer to WCAG 2.0 "conformance", but instead refer to "meeting WCAG 2.0 success criteria".
Once an authoring tool has been installed and put into use, it would be possible to assess the WCAG 2.0 conformance of the web content that the authoring tool produces, including whether the WCAG 2.0 accessibility-supported requirement is met. However, this WCAG 2.0 conformance assessment would be completely independent of the authoring tool's conformance with ATAG 2.0.
Conformance Options and Levels
There are two types of conformance, each with three levels:
ATAG 2.0 Conformance (Level A, AA, or AAA)
This conformance option may be selected when an authoring tools can be used to produce accessible web content (WCAG) without additional tools or components. The level of conformance is determined as follows:
- Level A: The authoring tool satisfies all of the applicable Level A success criteria.
- Level AA: The authoring tool satisfies all of the applicable Level A and Level AA success criteria.
- Level AAA: The authoring tool satisfies all of the applicable success criteria.
Note 1: The Part A Conformance Applicability Notes and Part B Conformance Applicability Notes must be applied.
Note 2: If the minimum conformance level (Level A) has not been achieved (i.e., at least one applicable Level A success criterion has not been met), it is still beneficial to publish a statement specifying which success criteria were met.
Partial ATAG 2.0 Conformance - Process Component (Level A, AA, or AAA)
This conformance option may be selected when an authoring tool would require additional tools or components in order to conform as a complete authoring system. This option may be used for components with very limited functionality (e.g. a plug-in) up to nearly complete systems (e.g. a markup editor that only lacks accessibility checking functionality).
The level of conformance (A, AA, or AAA) is determined as above except that, for any "no" answers, the tool must not prevent the success criteria from being met by another authoring process component as part of a complete authoring system.
Note 1: Authoring tools would not be able to meet partial conformance if they prevent additional authoring process components from meeting the failed success criteria (e.g., for security reasons).
Note 2: The Part A Conformance Applicability Notes and Part B Conformance Applicability Notes must be applied.
Partial ATAG 2.0 Conformance - Platform Limitations (Level A, AA, or AAA)
This conformance option may be selected when an authoring tool is unable to meet one or more success criteria because of intrinsic limitations of the platform (e.g., lacking a platform accessibility service). The (optional) explanation of conformance claim results should explain what platform features are missing.
Web Content Technologies Produced:
Authoring tools conform to ATAG 2.0 with respect to the production of specific web content technologies (e.g., Level A Conformance with respect to the production of XHTML 1.0).
If an authoring tool is capable of producing multiple web content technologies, then the conformance may include only a subset of these technologies as long as the subset includes both any technologies that the developer sets for automatically-generated content or that the developer sets as the default for author-generated content. The subset may include "interim" formats that are not intended for publishing to end users, but this is not required.
Live publishing authoring tools:
ATAG 2.0 may be applied to authoring tools with workflows that involve live authoring of web content (e.g., some collaborative tools). Due to the challenges inherent in real-time publishing, conformance to Part B of ATAG 2.0 for these authoring tools may involve some combination of support before (e.g., support in preparing accessible slides), during (e.g., live captioning as WCAG 2.0 requires at Level AA) and after the live authoring session (e.g., the ability to add a transcript to the archive of a presentation that was initially published in real-time). For more information, see the Implementing ATAG 2.0 - Appendix E: Authoring Tools for Live Web Content.
Note: As with any software application, authoring tools can be collections of components. A conformance claim can only be made by a responsible entity. Any other attempted "claims" are, in fact, reviews.
Required Components of a Conformance Claim
- Date of the claim.
- Guidelines title, version and URI "Authoring Tool Accessibility Guidelines 2.0 at @@"
- Conformance level satisfied.
- Authoring tool information: The name of the authoring tool and sufficient additional information to specify the version (e.g., vendor name, version number (or version range), required patches or updates, human language of the user interface or documentation).
- Note: 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.
- Platform(s): The platform(s) upon
which the authoring tool operates:
- A list of the web content technologies produced by the authoring tool that are included in the claim. If there are any web content technologies produced by the authoring tool that are not included in the conformance claim, these must be listed separately.
- Results for each of the success criteria: Yes, No, Not Applicable
Optional Components of a Conformance Claim
In addition to the required components of a conformance claim above, consider providing additional information to assist authors. Recommended additional information includes:
- An explanation of the success criteria results (Yes, No). (strongly recommended)
- Information about how the web content technologies produced can be used to create accessible
web content (e.g., links to technology-specific WCAG 2.0 techniques).
- Information about any additional steps taken that go beyond the success criteria to enhance accessibility.
- A machine-readable metadata version of the conformance claim.
- A description of the authoring tool that identifies the types of editing-views that it includes.
Neither W3C, WAI, nor AUWG take any responsibility for any aspect or result of any ATAG 2.0 conformance
claim that has not been published under the authority of the W3C, WAI, or AUWG.
Appendix A: Glossary
This section is normative.
This appendix contains definitions for all of the significant/important/unfamiliar terms used in the normative parts of this specification, including terms used in the Conformance section. Please consult http://www.w3.org/TR/qaframe-spec/ for more information on the role of definitions in specification quality.
- accessibility problems
- ATAG 2.0 recognizes two types of accessibility problems:
- authoring tool user interface accessibility problems:
Aspects of an authoring tool user interface that does not meet a success criterion in Part A of ATAG 2.0.
- web content accessibility problems (WCAG):
Aspects of web content that does not meet a WCAG 2.0 success criterion (Level A, AA or AAA).
- accessibility information (WCAG)
- Information that web content must contain in order to meet a WCAG 2.0 success criterion (Level A, AA or AAA). Examples include: programmatically associated alternative content (e.g., text alternatives for images), role and state information for widgets, relationships within complex tables).
Note: For the purposes of ATAG 2.0, only programmatically determinable information qualifies. For additional examples, see Appendix A of the Implementing ATAG 2.0 document.
- accessible content support features
- Any features of an authoring tool that directly support authors in increasing the accessibility of the web content being edited. These are features that must be present to meet the success criteria in Part B of ATAG 2.0.
- alternative content
- Web content that is used in place of other content that some people are not able to access. Alternative content fulfills essentially the same function or purpose as the original content. WCAG 2.0 recognizes several general types of alternative content (for more information see WCAG 2.0):
Importantly, from the perspective of authoring tools, alternative content may or may not be:
- text alternatives for non-text content: Text that is programmatically associated with non-text content or referred to from text that is programmatically associated with non-text content. For example, an image of a chart might have two text alternatives: a description in the paragraph after the chart and a short text alternative for the chart indicating in words that a description follows.
- alternatives for time-based media: Web content that serves
the same function or purpose as one or more tracks in a time based media presentation. This includes: captions, audio descriptions, extended audio descriptions, sign language interpretation as well as correctly sequenced text descriptions of time-based visual and auditory information that also is capable of achieving the outcomes of any interactivity in the time-based presentation.
- media alternative for text: Media that presents no more information than is already presented in text (directly or via text alternatives). A media alternative for text is provided for those who benefit from alternate representations of text. Media alternatives for text may be audio-only, video-only (including sign-language video), or audio-video.
Note: ATAG 2.0 typically refers to programmatically associated alternative content.
programmatically associated: Alternative content whose location and purpose can be programmatically determined from the original content for which it is serving as an alternative. For example, a paragraph might serve as a text alternative for an image, but it is only programmatically associated if this relationship is properly encoded (e.g., by "aria-labeledby").
- ASCII art
- A picture created by a spatial arrangement of characters or glyphs (typically from the 95 printable characters defined by ASCII).
- assistive technology
- Software (or hardware), separate from the authoring tool, that provides functionality to meet the requirements of users with disabilities. Some authoring tools may also provide direct accessibility features.
- 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;
- speech 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 (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices);
- alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
- The technology of sound reproduction. Audio can be created synthetically (including speech synthesis), recorded from real-world sounds, or both.
- author actions preventing generation of accessible web content
- When the actions of authors prevents authoring tools from generating accessible web content (WCAG). Examples include: turning off accessibility options, ignoring prompts for accessibility information (WCAG), providing faulty accessibility information (WCAG) at prompts, modifying the authoring tool (e.g., via scripting, macros), and installing plug-ins.
- People who use authoring tools to create or modify
web content. The term may cover roles such as content authors, designers, programmers, publishers, testers, etc. (see also Part B Conformance Applicability Note 6: Multiple authoring roles). Some authoring tools control who may be an author by managing author permissions.
- author permission
- Authorization that allows modification of given web content.
- authoring action
- Any action that authors can take using the authoring tool user interface that results in editing web content (e.g., typing text, deleting, inserting an element, applying a template). In contrast, most authoring tool user interfaces also enable actions that do not edit content (e.g., saving, publishing, setting preferences, viewing documentation).
- reversible authoring action is an authoring action that can be immediately and completely undone by the authoring tool upon a cancel request by an author. Examples of cancel requests include: "cancel", "undo", "redo" (when it used to reverse "undo"), "revert", and "roll-back"
Note: It is acceptable to collect a series of text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action..
- authoring outcome
- The content or content modifications that result from authoring actions. Authoring outcomes are cumulative (e.g., text is entered, then styled, then made into a link, then given a title).
- authoring practice
- An approach that authors follow to achieve a given authoring outcome. (e.g., controlling presentation with style sheets). Depending on the design of an authoring tool, authoring practices may be chosen by the authors or by the authoring tool. Authoring practices may or may not be:
- authoring session
- A state of the authoring tool in which web content can be edited by an author.
- end of an authoring session: The point at which the author has no further opportunity to make changes without starting another session. The end of an authoring session may be determined by authors (e.g., closing a document, publishing) or by the authoring tool (e.g., when the authoring tool transfers editing permission to another author on a collaborative system). Note that the end of the authoring session is distinct from publishing. Automatic content generation may continue after the end of both the authoring session and initial publishing (e.g., content management system updates).
- authoring tool
- Any web-based or non-web-based application(s) that can be used by authors (alone or collaboratively) to create or modify web content for use by other people (other authors or end users).
Note 1: "application(s)": ATAG 2.0 may be conformed to by stand-alone applications or by collections of applications. If a conformance claim is made, then the claim must provide identifying information for each application and also for any required extensions, plug-ins, etc.
Note 2: "alone or collaboratively": Multiple authors may contribute to the creation of web content and, depending on the authoring tool, each author may work with different views of the content and different author permissions.
Note 3: "to create or modify web content": This clause rules out software that collects data from a person for other purposes (e.g., online grocery order form) and then creates web content from that data (e.g., a web-based warehouse order) without informing the person (however, WCAG 2.0 would still apply). This clause also rules out software used to create content exclusively in non-web content technologies.
Note 4: "for use by other people": This clause rules out the many web applications that allow people to modify web content that only they themselves experience (e.g., web-based email display settings) or that only provide input to automated processes (e.g., library catalog search page).
Examples of software that are generally considered authoring tools under ATAG 2.0:
Examples of software that are not considered authoring tools under ATAG 2.0 (in all cases, WCAG 2.0 still applies if the software is web-based):
- web page authoring tools (e.g., WYSIWYG HTML editors)
- software for directly editing source code
- software for converting to web content technologies (e.g., "Save as HTML" features in office document applications)
- integrated development environments (e.g., for web application development)
- software that generates web content on the basis of templates, scripts, command-line input or "wizard"-type processes
- software for rapidly updating portions of web pages (e.g., blogging, wikis, online forums)
- software for generating/managing entire web sites (e.g., content management systems, courseware tools, content aggregators)
- email clients that send messages using web content technologies
- multimedia authoring tools
- software for creating mobile web applications
- customizable personal portals: ATAG 2.0 does not apply because the web content being edited is only available to the owner of the portal
- e-commerce order forms: ATAG 2.0 does not apply because the purpose of an e-commerce order form is to order a product, not communicate with other people via web content, even if the data collected by the form actually does result in web content (e.g., online tracking pages)
- stand-alone accessibility checkers: ATAG 2.0 does not apply because a stand-alone accessibility checker with no automated or semi-automated repair functionality does not actually modify web content. An accessibility checker with repair functionality or that is considered as part of a larger authoring process would be considered an authoring tool.
tool user interface
- The display and control mechanism that authors use to operate the authoring tool software. User interfaces may be non-web-based or web-based or a combination (e.g., a non-web-based authoring tool might have web-based help pages):
Authoring tool user interfaces may or may not be:
- authoring tool user interface (non-web-based): Any parts of an authoring tool user interface that are not implemented as web content and instead run directly on a platform that is not a user agent (e.g., Windows, Mac OS, Java Virtual Machine).
- authoring tool user interface (web-based): Any parts of an authoring tool user interface that are implemented using web content technologies and are accessed by authors via a user
authoring tool user interfaces: Authoring tool user interfaces that meet the success criteria of a level in Part A of ATAG 2.0.
- checking, accessibility
- The process by which web content is evaluated for web content accessibility problems (WCAG). ATAG 2.0 recognizes three types of checking, based on increasing levels of automation of the tests:
- manual checking: Checking in which the tests are carried out by authors. This includes the case where authors are aided by instructions or guidance provided by the authoring tool, but where authors must carry out the actual test procedure.
- semi-automated checking: Checking in which 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.
- automated checking: Checking in which the tests are carried out automatically by the authoring tool without any intervention by authors. An authoring tool may support any combination of checking types.
of software components
- Any software programs that are 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 software components.
- content (web content)
- Information and sensory experience to be communicated to the end user by means of a user
agent, including code or markup that defines the content's structure, presentation, and interactions. In ATAG 2.0, the term is primarily used to refer to the output that is produced by the authoring tool. Content produced by authoring tools may include web applications, including those that act as web-based authoring tools. Content may or may not be:
- accessible content (WCAG): Content that would conform to WCAG 2.0, at either Level A, AA, or AAA, assuming that any web content technologies relied upon to satisfy the WCAG 2.0 success criteria are accessibility supported.
- Note 1: If accessibility support for the relied upon technologies is lacking, then the content will not conform to WCAG 2.0 and one or more groups of end users with disabilities will likely experience difficulty accessing the content.
- Note 2: Conformance to WCAG 2.0, even at the highest level (i.e., Level AAA), still may not make content "accessible to individuals with all types, degrees, or combinations of disability".
- content being edited: The web content that an author can modify during an authoring session. The content being edited may be a complete piece of content (e.g., image, style sheet) or only part of a larger piece of content (e.g., a status update). The content being edited only includes content in web content technologies that the authoring tool supports (e.g., a WYSIWYG HTML editor allows editing of the HTML content of a web page editable, but not the images).
- content properties
- The individual pieces of information that make up the web content (e.g., the attributes and contents of elements, stylesheet information).
- content (structured)
- Web content that includes machine-readable internal structure (e.g., markup elements), as opposed to unstructured
content, such as raster image formats or plain human language text.
- content generation (content authoring, content editing)
- The act of specifying the actual web
content that will be rendered, played or executed by the end user's user agent. While the precise details of how content is created in any given system may vary widely, responsibility for the generation of content can be any combination of the following:
- author generated content: Web content for which authors are fully responsible. The author may only be responsible down to a particular level (e.g., when asked to type a text label, the author is responsible for the text, but not for how the label is marked up; when typing markup in a source editing-view, the author is not responsible for the fact that UNICODE is used to encode the text ).
- automatically generated content: Web content for which developer-programmed functionality is fully responsible (e.g., what markup to output when an author requests to start a new document, automatically correcting markup errors).
- third-party content generation: Web content for which a third-party author is responsible (e.g., community shared templates).
- content rendering
- User interface
functionality that authoring tools present if they render, play or execute the web content being edited. ATAG 2.0 recognizes several types of content renderings:
- conventional renderings (or "WYSIWYG"): When content is rendered in a way that is similar to the default rendering a user agent would create from the same content. While "WYSIWYG", standing for "What-you-see-is-what-you-get" is the common term, differences between user agents and end user settings mean that in reality there is no single typical end user experience; or
- unconventional renderings: When content is rendered differently than it would be in a typical user agent (e.g., rendering an audio file as a graphical wavefront); or
- partial renderings: When some aspects of the content are rendered, played, or executed, but not others
(e.g., a frame-by-frame video editor renders the graphical, but not the timing aspects, of a video).
- content transformations
- Processes that take content in one web content technology or
non-web content technology (e.g., a word processing format) as input and produce content that has been optimized, restructured or recoded:
Note: Clipboard operations, in which content is copied to or pasted from the platform clipboard, are not considered content transformations.
- Optimizing Content Transformations: Transformations in which the content technology is not changed and the structural features of the content technology that are employed also stay the same. Changes would not be expected to result in information loss (e.g., removing whitespace, replacing in-line styles with an external stylesheet).
- Restructuring Content Transformations: Transformations in which the content technology stays the same, but the structural features of the technology used to markup the content are changed (e.g., linearizing tables, splitting a document into pages.
- Recoding Content Transformations: Transformations in which the content technology used to encode the content is changed (e.g., HTML to XHTML, a word processing format to HTML).
- control settings
- Settings that relate to how authors operate the authoring tool, for example using the keyboard or mouse.
- Any entities or individuals responsible for programming the authoring tool. This includes the programmers of any additional software components included by the Claimant in the conformance claim. In some cases, development of the authoring tool is complete before authors can use it to publish web
content. However, in other cases (e.g., some web-based authoring tools), the developer may continue to modify the authoring tool even after content has been published, such that the
content experienced by the end user is modified.
- direct accessibility features
- Features of an authoring tool that provide functionality to meet the requirements of authors with disabilities (e.g., keyboard navigation, zoom features, text-to-speech). Additional or specialized functionality may still be provided by external assistive technology.
- display settings
- Settings that relate to how authors perceive the authoring tool. These include:
- audio display settings: the characteristics of audio output of music, sounds and speech. Examples include volume, speech voices,
voice speed, and voice emphasis.
- visual display settings: the characteristics of
the on-screen rendering of text and graphics. Examples include fonts, sizes,
colors, spacing, positioning, and contrast.
- tactile display settings: the characteristics of haptic output. Examples include the magnitude of the haptic forces and the types of vibration.
- Any information that supports the use of an authoring tool. This information may be provided electronically or otherwise and includes help, manuals, installation instructions, sample work flows, tutorials, etc.
- document object
- The internal representation of data in the source by a non-web based authoring tool or user agent. The document object may form part of a platform accessibility service that enables communication with assistive technologies. Web-based authoring tools are considered to make use of the document object that is maintained by the user
- A pair of markup tags and its content, or an "empty tag"
(one that requires no closing tag or content).
- end user
- A person who interacts with web
content once it has been authored. This includes people using assistive technologies.
- human language
- Language that is spoken, written or signed (through visual or tactile means) to communicate with humans.
- For information purposes and not required for conformance.
- keyboard interface
- Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g., a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected).
Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.
- keyboard trap
- A user interface situation in which a keyboard interface may be used to move focus to, but not from, a user interface component or group of components.
- Text or other component with a text alternative that is presented to users to identify a component. A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same.
- Information captured from a real-world event that is published with no more than a broadcast delay.
Note: A broadcast delay is a short (usually automated) delay, for example used in order to give the broadcaster time to queue or censor the audio (or video) feed, but not sufficient to allow significant editing.
- markup language
- A system of text annotations (e.g., elements in HTML) and processing rules that may be used to specify the structure, presentation or semantics of content. Examples of markup languages include HTML and SVG.
- markup of some content is the set of annotations that appear in the content.
- Text by which software can identify a user interface component to the author or end user. The name may be hidden and only exposed by assistive technology, whereas a label is presented to all users. In many (but not all) cases, the label and the name are the same.
- non-text content
- Any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language. This includes ASCII Art (which is a pattern of characters), emoticons, and images representing text.
- Required for conformance. One may conform in a variety of well-defined ways to ATAG 2.0. Content identified as "informative" or "non-normative" is never required for conformance.
- When an author is presented with choices.
- default option: A setting or value for an option that is assigned automatically by the authoring tool and remains in effect unless canceled or changed by the author.
- The software environment within which the authoring tool operates. Platforms provide a consistent operational environment on top of lower level software platforms or hardware. For web-based authoring user interfaces, the most relevant platform will be a user agent (e.g., browser). For non-web-based user interfaces, the range of platforms includes, but may not be limited to, desktop operating systems (e.g., GNOME desktop on Linux, Mac OS, Windows), mobile operating systems (e.g., Android, BlackBerry, iOS, Windows Phone), or cross-OS environments (e.g., Java), etc..
Note 1: Many platforms mediate communication between applications operating on the platform and assistive technology via a platform accessibility service.
Note 2: Accessibility guidelines for developers exist for many platforms.
- platform accessibility
- A programmatic interface that is specifically engineered to provide communication between applications and assistive technologies (e.g., MSAA, IAccessible2 and UI Automation for Windows applications, AXAPI for Mac OS X applications, GNOME Accessibility Toolkit API for GNOME applications, Java Access for Java applications). On some platforms, it may be conventional to enhance communication further by implementing a document object.
- A program that runs as part of the authoring tool (e.g., a third-party checking and repair tool) and that is not part of web content being edited. Authors generally
choose to include or exclude plug-ins from their authoring tool.
- Rendering of the content in a form
to be perceived by authors or end users.
- programmatically determined (programmatically determinable)
- Information that is encoded in a way that allows different software, including assistive technologies, to extract and present the information in different modalities. ATAG 2.0 uses this term in two contexts:
- A heuristic measure of how likely users are to notice a user interface component in a user interface that
they are operating. Prominence is affected by numerous factors,
including: the number of navigation steps required, the reading order
position, visual properties (e.g., size, spacing, color), and even the
modality of use (e.g., mouse vs. keyboard use).
- at least as
prominent: For ATAG 2.0, a user interface component A is considered to be "at least as prominent" as another component B when, from a default state, component A becomes displayed (and enabled) with the same number or less "opening" actions than are required for component B to become displayed (and enabled).
Note 1: When a container is open, all of the enabled components in the container (e.g., items in a list, items in a menu, buttons in a toolbar, all components in a dialog box) are considered to be displayed (and therefore are at least as prominent as each other), even if the container must be scrolled for them to become visible. This takes into account that different screen sizes and author settings will affect which components are visible at a given time.
Note 2: "Opening actions" are actions made by authors on components within the user interface that result in new components becoming displayed or enabled. For example: (a) keyboard shortcut to a top-level menu item to display a sub-menu, (b) keyboard selection on a button to display a dialog box, (c) mouse click on a checkbox to enable previously disabled sub-items, etc.. Actions that do not cause new components to become actionable (e.g., moving focus, scrolling a list), are not counted as "opening actions".
Note 3: Keyboard shortcuts to components in closed containers are not counted as "opening actions" because the components have no prominence when they are not displayed. The same is true when authors must use "search" to reveal components in closed containers.
Note 4: The "default state" is the state of the authoring tool at the beginning of an authoring session as set by the developer. The default state of many document authoring tools is an editing-view.
- Any authoring tool initiated
request for a decision or piece of information from authors. The term covers requests that must be responded to immediately (e.g. modal dialog boxes) as well as less urgent requests (e.g. underlining a misspelled word).
- Any point at which the authors or authoring tool make web content available to end users (e.g., uploading a web page, committing a change in a wiki, live streaming).
- More than one item within a multi-item set.
Informative Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not be practical (e.g., the set of all help documentation examples, the set of all templates). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly.
- Meaningful associations between distinct pieces of content.
- repair (accessibility)
- The process by which web
content accessibility problems that have been identified within web content are resolved. ATAG 2.0 recognizes three types of repair,
based on increasing levels of automation:
- manual repair: Where the repairs are carried out by authors. This includes the case where authors are aided by instructions or guidance provided by the authoring tool, but where authors carry out the actual repair procedure;
- semi-automated repair: 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 repair: Where the repairs are carried out automatically by the authoring tool without any intervention by authors.
- restrictions, restricted web content authoring
- When the web content that authors can specify with an authoring tool either must include or must not include certain content (e.g., elements, attributes, widgets). Many authoring tools restrict authoring in some way, which can either benefit accessibility (e.g., if text alternatives for non-text content are required) or detract from accessibility (e.g., if attributes for defining text alternatives are not available). In contrast, authoring tools that allow unrestricted web content authoring do not require any particular content to be included or not included (e.g., many source editing-views).
- Text or a number by which software can identify the function of a component within web content (e.g., a string that indicates whether an image functions as a hyperlink, command button, or check box).
- sequential keyboard access
- Using a keyboard interface to navigate the focus one-by-one through all of the items in an ordered set (e.g., menu items, form fields) until the desired item is reached and activated. This is in contrast to direct keyboard access methods such as keyboard shortcuts and the use of bypass links.
- technology (web content)
- Content patterns that are filled in by authors or the authoring tool to produce content for end users (e.g., document templates, content management templates, presentation themes). Often templates will pre-specify at least some authoring decisions.
- accessible templates (WCAG): Templates that can be filled in to create web content that meets the WCAG 2.0 success criteria (Level A, AA or AAA), when both of the following are true:
Note: Under these conditions, some templates will result in completely empty documents, which are considered accessible by default.
- The author correctly follows any instructions provided (e.g., correctly responding to prompts, correctly replacing highlighted placeholders); and
- No further authoring occurs
- template selection mechanism
- A function beyond standard file selection that allows authors to select templates to use as the basis for new content or to apply to existing content.
- A type of documentation that provides step-by-step instructions for performing multi-part tasks.
- Any software that retrieves, renders and facilitates end user interaction with web content. Examples include web browsers, browser plug-ins, and media players.
- user interface component
- A part of the user interface or content display (including content renderings) that is perceived by authors as a single control for a distinct function.
- The technology of moving pictures or images. Video can be made up of animated or photographic images, or both.
- A user interface function that authors use to interact with the web content being edited. ATAG 2.0 categorizes views according to whether they support editing:
ATAG 2.0 also recognizes several approaches to presenting the content in a view:
- editing-views: View in which some or all of the content is editable; or
- previews: Views in which no authoring actions are provided (i.e., the view is not editable). Typically, the purpose of previews is to present content as it would appear to end users of user
agents. In these cases, previews may be implemented using existing user agents or they may attempt to emulate some user agent functionality.
- A customary sequence of steps or tasks that authors follow to produce a content deliverable. If an authoring tool is composed of a collection
of software components, then its workflows may include use of one or more of the components.
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:
- 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:
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:
"Authoring Tool Accessibility Guidelines 2.0,"</a></cite>
J. Richards, J. Spellman, J. Treviranus, eds.,
W3C Recommendation, http://www.w3.org/TR/ATAG20/.
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
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.
- "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/.
- "User Agent Accessibility Guidelines
1.0," I. Jacobs, J. Gunderson, E. Hansen, eds.17 December 2002. This W3C Recommendation is available at http://www.w3.org/TR/2002/REC-UAAG10-20021217/.
- "Web Content Accessibility Guidelines 2.0 ", B. Caldwell, M. Cooper, L. Guarino Reid, and G. Vanderheiden.
Appendix D: Acknowledgments
- Jan Richards (Adaptive Technology Resource Centre, University of Toronto)
- Jeanne Spellman (W3C)
- Roberto Scano (IWA/HWG)
Participants active in the AUWG at the time of publication:
- Tim Boland (National Institute for Standards and Technology)
- Alastair Campbell (Nomensa)
- Cherie Ekholm (Microsoft)
- Alex Li (Microsoft)
- Alessandro Miele (Invited Expert)
- Sueann Nichols (IBM)
- Greg Pisocky (Adobe)
- Jan Richards (Inclusive Design Institute, OCAD University)
- Andrew Ronksley (RNIB)
- Roberto Scano (IWA/HWG)
- Jeanne Spellman (W3C)
- Jutta Treviranus (WG Chair; Inclusive Design Institute, OCAD University)
Other previously active AUWG participants and other contributors to ATAG 2.0:
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Barry A. Feigenbaum, Katie Haritos-Shea, Kip Harris, Phill Jenkins, Len Kasday, Marjolein Katsma, William Loughborough, Karen Mardahl, Matt May, Charles McCathieNevile, Ann McMeekin, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Sarah Pulis, Bob Regan, Chris Ridpath, Andrew Ronksley, Gregory Rosmaita, Dana Simberkoff, Reed Shaffner, Michael Squillace, 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, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED-OSE-10-C-0067. 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.