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/.
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.
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.
Notes:
- The term "authoring tools" has a specific definition in ATAG 2.0. The definition, which includes several normative notes, appears in the Glossary.
- ATAG 2.0 recommends that authoring tools be capable of producing web content that conforms with WCAG 2.0. However, WCAG 2.0 notes 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, particularly in the cognitive language and learning areas". Development of authoring tools that address more specialized needs is encouraged, but is beyond the scope of this document.
- 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 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 accessible authoring tools. Part A relates to ensuring the accessibility of authoring tool user interfaces to authors with disabilities. Part B relates to ensuring support by authoring tools for the creation, by any author (not just those with disabilities), of web content that is accessible to end
users with disabilities. Both parts include normative applicability notes that apply to all of the success criteria within that part (see Part A Applicability Notes, Part B 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).
Integration of Accessibility Features
When implementing ATAG 2.0, authoring tool developers should carefully integrate features that support 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.
Guidelines
The success criteria and 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 content being edited and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation, etc.
- Reflected content accessibility problems: The authoring tool is responsible for ensuring that editing-views display the content being edited in a way that is accessible to authors with disabilities (e.g. ensuring that text alternatives in the content can be programmatically determined). However, where an 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. It does not apply to any subsequent modifications by parties other than the authoring tool developer (e.g. by plug-ins, user modifications, etc.).
- User agent features: Web-based authoring tools may rely on user agent features (e.g. keyboard navigation, find functions, display preferences, undo features, etc.) to satisfy success criteria. If a conformance claim is made, the claim must cite the user agent.
- Features for meeting Part A must be accessible: 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, etc.). 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.
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.
[Implementing A.1.1]
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): Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria. [Implementing A.1.1.1]
The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
Guideline A.1.2: (For the authoring tool user interface) Ensure that non-web-based functionality is accessible.
[Implementing A.1.2]
Rationale: When authoring tools (or parts of authoring tools) are non-web-based, following existing 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.
[Implementing A.2.1]
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.
[Implementing A.2.2]
Rationale: Some authors need access to details about the editing-view presentation, via their assistive technology, when presentation is used to convey status information (e.g. underlining misspelled words) or provide information about how the end user will experience the web content being edited.
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 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) [Implementing A.3.1.1]
Note 1: 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 2: This success criterion does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
A.3.1.2 No Keyboard Traps: Keyboard traps are prevented as follows: (Level A) [Implementing A.3.1.2](a) In the Authoring Tool User Interface: 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, the user is advised of the method for moving focus away; and
(b) In Editing-Views that Render Content: If an editing-view renders content (e.g. WYSIWYG view), then a documented keyboard command is provided that moves the editing-view keyboard focus to a known location (e.g. the start of the editing-view).
Guideline A.3.2: (For the authoring tool user interface) Provide authors with enough time.
[Implementing A.3.2]
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 Content Edits Saved (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool saves all edits made by authors. (Level A) [Implementing A.3.2.1]
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) [Implementing A.3.2.2]
(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 Pointer Targets: Authoring tool user interface components that accept
pointer input are either stationary or authors can pause the movement. (Level A) [Implementing A.3.2.3]
Guideline A.3.3: (For the authoring tool user interface) Help authors avoid flashing that could cause seizures.
[Implementing A.3.3]
Rationale: Flashing can cause seizures in authors with photosensitive seizure disorder.
A.3.3.1 Static View Option: Editing-views that render visual time-based content can be paused and can be set to not play automatically. (Level A) [Implementing A.3.3.1]
Guideline A.3.4: (For the authoring tool user interface) Enhance navigation and editing via content structure.
[Implementing A.3.4]
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 the tasks of navigation 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, etc.) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA) [Implementing A.3.4.1]
Guideline A.3.5: (For the authoring tool user interface) Provide text search of the content.
[Implementing A.3.5]
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 authored.
A.3.5.1 Text Search: Authors can perform text searches of web content that meet the following: (Level AA) [Implementing A.3.5.1]
(a) Search All Editable: Any information that is text and that the authoring tool can modify is searchable, including: text content, text alternatives for non-text content, metadata, markup elements and attributes; and
Note: If the current editing-view is not able to display the results of a search, then the athoring tool may provide a mechanism to switch to a different editing-view to display the results.(b) Two-way: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case insensitive modes; and
(d) No Match: Authors are informed when no results are found.
Guideline A.3.6: (For the authoring tool user interface) Manage preference settings.
[Implementing A.3.6]
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 as accessible as existing user agents.
[Implementing A.3.7]
Rationale: Preview features are provided in 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) [Implementing A.3.7.1]
(a) Pre-existing User Agent: The preview makes use of a pre-existing user agent; or
(b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [UAAG].
PRINCIPLE A.4: Editing-views must be understandable
Guideline A.4.1: (For the authoring tool user interface) Help authors avoid and correct mistakes.
[Implementing A.4.1]
Rationale: Some authors who have difficulty making fine movements may be prone to making unintended actions.
A.4.1.1 Content Changes Reversible (Minimum): For authoring actions, one of the following are true: (Level A) [Implementing A.4.1.1]
Note 1: Reversing actions (e.g. an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g., a "redo" function).
Note 2: 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.
Note 3: It is acceptable to clear the authoring action history at the end of authoring sessions.
(a) Reversible: The authoring action can be immediately reversed; or
(b) Warn and Confirm: The authoring tool includes a warning to authors that the action is irreversible and requires authors to confirm the action before proceeding.
A.4.1.2 Setting Changes Reversible: If actions modify authoring tool settings, then one of the following are true: (Level A) [Implementing A.4.1.2]
(a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or
(b) Warn and Confirm: The authoring tool includes a warning to authors that the action is irreversible and requires authors to confirm the action or save the current settings before proceeding.
Guideline A.4.2: (For the authoring tool user interface) Document the user interface including all accessibility features.
[Implementing A.4.2]
Rationale: Some authors may not be able to understand or operate the authoring tool user interface without proper accessible documentation.
PART B: Support the production of accessible content
Applicability Notes @@Part B Conformance Conditions:
- 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. by plug-ins, user-defined templates, user modifications of default settings, etc.).
- Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session. 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 has specified, 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).
- Features for meeting Part B must be accessible: 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, etc.).
- Multiple author 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 author role. Accessible content support features should be made available to any author role where it would be useful.
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 that is not accessible, then additional repair tasks are imposed on authors.
@@B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG): Authors have the default option that, when web content is automatically generated during an authoring session, then one of the following is true: [Implementing B.1.1.2]
@@Note 1: Automatic generation includes automatically selecting templates for authors.
Note 2: This success criterion applies only to automatic processes specified by the authoring tool developer. It does not apply when author actions prevent generation of accessible web content.
(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. The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
@@Perhaps this can be combined with proposed Note 1 on B.1.1.2 B.1.1.3 Template Auto-Selection (WCAG): Authors have the default option that only accessible templates (WCAG) are automatically selected by the authoring tool. [Implementing B.1.1.3]
The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
Guideline B.1.2: Ensure accessibility information is preserved. [Implementing B.1.2]
Rationale: Accessibility information is critical to maintaining comparable levels of accessibility 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, then at least one of the following is true: [Implementing B.1.2.1]
Note: This success criteria only applies to transformations in which the output technology is an "included" technology for conformance.(a) Preserve: Accessibility information (WCAG) is preserved in the output; or
(b) Warning:.Authors have the default option to be warned that accessibility information 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. The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
PRINCIPLE B.2: Authors must be supported in producing accessible content
Guideline B.2.1: Ensure accessible content production is possible.
[Implementing B.2.1]
Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web content (WCAG) requirements. To support accessible web content production, at minimum, it must be possible to produce web content that conforms with WCAG 2.0 using the authoring tool.
http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0100.html
B.2.1.1 Accessible Content Production (WCAG): Authors can use the authoring tool to produce accessible web content (WCAG): [Implementing B.2.1.1]
The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
Guideline B.2.2: Guide authors to produce accessible content.
[Implementing B.2.2]
Rationale: By guiding authors from the outset towards 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) [Implementing B.2.2.1] The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
B.2.2.2 Setting Accessibility Properties (WCAG): If the authoring tool provides mechanisms to set web content properties (e.g. attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information (WCAG): [Implementing B.2.2.2]
Note: Success Criterion B.3.2.4 addresses the prominence of the mechanisms. The WCAG 2.0 Level A success criteria are met (Level A); or
The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
Guideline B.2.3: Assist authors with managing alternative content for non-text content.
[Implementing B.2.3]
Rationale: Improperly generated alternative content can create accessibility problems and interfere with accessibility checking.
See Also: This guideline applies when non-text content is specified by authors (e.g. inserts an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.1.
Guideline B.2.4: Assist authors with accessible templates.
[Implementing B.2.4]
Rationale: Providing accessible accessible templates and other pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can have several benefits, including: immediately improving the accessibility of web content being edited, reducing the effort required of authors, and demonstrating the importance of accessible web content (WCAG) .
Guideline B.2.5: Assist authors with accessible pre-authored content. [Implementing B.2.5]
Rationale: Providing accessible templates and other pre-authored content (e.g. clip art, synchronized media, widgets, etc.) can have several benefits, including: immediately improving the accessibility of web content 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) [Implementing B.2.5.1] (a) Indicate: The selection mechanism indicates the accessibility status of the pre-authored content (if known); and (b) Prominence: Any accessible options are at least as prominent as other pre-authored content options.
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) [Implementing B.2.5.2]
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: Accessibility checking as an integrated function of the authoring tool helps make authors aware of web content accessibility problems during the authoring process, so they can be immediately addressed.
B.3.1.4 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA) [Implementing B.3.1.4]
Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc.
B.3.1.5 Metadata Production: Authors have the option of associating accessibility checking results with the web content as metadata. (Level AA) [Implementing B.3.1.5]
Note: The metadata format that is implemented will dictate the nature of the associated results (e.g. specific check results, summary conformance claims, etc.)
Guideline B.3.2: Assist authors in repairing accessibility problems. [Implementing B.2.3]
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.
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.
[Implementing B.4.1]
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.
[Implementing B.4.2]
Rationale: Without documentation of the features that support the production of accessible content (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be able to use them. Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.
Conformance
Conformance means that the authoring tool satisfies the success criteria defined in the
guidelines section.
This conformance section describes conformance and lists the conformance requirements.
Relationship
to the Web Content Accessibility Guidelines (WCAG) 2.0
Because WCAG 2.0 [WCAG20] is the most recent W3C Recommendation regarding web content accessibility, ATAG 2.0 frequently refers to WCAG 2.0 in order to set 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 towards producing web content that is accessible to end users with disabilities (in Part B).
@@Whenever success criteria or defined terms in ATAG 2.0 depend on WCAG 2.0, they are marked with "(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, etc.). Therefore:
For the purposes of ATAG 2.0 conformance, the accessibility-supported requirement is waived.
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 Requirements
In order for an authoring tool to conform to ATAG 2.0, all of the following conformance requirements must be satisfied:
Conformance Levels:
Authoring tools may conform "fully" or "partially" to ATAG 2.0. In either case, the level of conformance depends on the level of the success criteria that have been satisfied.
"Full" ATAG 2.0 Conformance: This type of conformance is intended to be used when developers have considered the accessibility of the authoring tools from both the perspective of authors (Part A: Make the authoring tool user interface accessible) and the perspective of end users of web content produced by the authoring tools (Part B: Support the production of accessible content):
- 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 AA
The authoring tool satisfies all of
the Level A and Level
AA success criteria.
- Full ATAG 2.0 Conformance at Level AAA
The authoring tool satisfies all of
the success criteria.
And the Part A Applicability Notes and Part B Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance: Authoring Tool User Interface: This type of conformance is intended to be used when developers have initially focused on the accessibility of the authoring tool to authors (Part
A: Make the authoring tool user interface accessible):
- 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 implied about Part B.
- Partial ATAG 2.0 Conformance Level AA:
Authoring Tool User Interface
The authoring tool satisfies all of the Level
A and Level AA success criteria in Part A. Nothing
is implied about Part B.
- Partial ATAG 2.0 Conformance Level AAA:
Authoring Tool User Interface
The authoring tool satisfies all of the success criteria
in Part A. Nothing is implied about Part B.
And the Part A Applicability Notes have been applied.
"Partial" ATAG 2.0 Conformance:
Content Production: This type of conformance is intended to be used when developers have initially focused on the accessibility of the web content produced by the authoring tool to end users (Part
B: Support the production of accessible content):
- 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 implied about Part A.
- Partial ATAG 2.0 Conformance Level AA:
Content Production
The authoring tool satisfies all of the Level
A and Level AA success criteria in Part B. Nothing
is implied about Part A.
- Partial ATAG 2.0 Conformance Level AAA:
Content Production
The authoring tool satisfies all of the success criteria
in Part B. Nothing is implied about Part A.
And the Part B Applicability Notes have been applied.
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 only as a step towards "Full" Conformance.
Web Content Technologies Produced:
Authoring tools conform to ATAG 2.0 with respect to the production of specific web content technologies (e.g. Full Level A conformance with respect to the production of XHTML 1.0, Partial Level AA Conformance: Content Production with respect to the production of SVG 1.1).
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 any technologies that the developer either sets for automatically-generated content or 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.
When Success Criterion B.2.1.1 refers to web content technologies for which the authoring tool provides support for the production of accessible content, it is referring to this subset.
Specialized Authoring Tools:
Some authoring tools provide a fairly limited set of authoring functions compared to the range of possible authoring functions addressed in these guidelines (e.g., a photo editor, a CSS editor, a status update field in a social networking application, etc.). In this case, most of the ATAG 2.0 requirements are simply not applicable, since most of the requirements are conditional on particular authoring functions being present (e.g., automatically generated content must only be accessible if this functionality exists).
Conformance
Claims (Optional)
If a conformance claim is made, then the conformance claim must meet the following conditions and include the following information (authoring tools can conform to ATAG 2.0 without making a claim). Claimants are encouraged to claim conformance to the most recent version
of the Authoring Tool Accessibility Guidelines Recommendation.
Conditions on Conformance Claims
- At least one version of the conformance claim must be published on the
web as a document meeting Level A of WCAG 2.0. A suggested metadata description
for this document is "ATAG 2.0 Conformance Claim".
- Whenever the claimed conformance level is published (e.g. product information web site), the URI for the on-line published version of the conformance
claim must be included.
- The existence of a conformance claim does not imply that the W3C has
reviewed the claim or assured its validity.
- Claimants are solely responsible for the accuracy of their claims and keeping claims up to date.
Required Components of an ATAG 2.0 Conformance Claim
- Claimant name and affiliation.
- Date of the claim.
- Guidelines title, version and URI
- 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. As stated above, the Claimant has sole responsibility for the conformance claim, not the developer of any of the software components.
- Web content technologies produced.
- A list of the web content technologies produced by the authoring tool that the Claimant is including in the conformance claim. For each web content technology, provide information on how the web content technology might be used to create accessible
web content (e.g. provide links to technology-specific techniques).
- A list of any web content technologies produced by the authoring tool that the Claimant is not including in the conformance claim.
- Declarations: For each success criterion:
- A declaration of whether or not the success criterion has been satisfied; or
- A declaration that the success criterion is not applicable and a rationale for why not.
- Platform(s): The platform(s) upon
which the authoring tool was evaluated:
Optional Components of an ATAG 2.0 Conformance Claim
- A description of the authoring tool that identifies the types of editing-views that it includes.
- A description of how the ATAG 2.0 success criteria were met where this may not be obvious.
"Progress Towards Conformance" Statement
Developers of authoring tools that do not yet conform fully to a particular
ATAG 2.0 conformance level are encouraged to publish a statement on progress
towards conformance. This statement would be the same as a conformance
claim except that this statement would specify an ATAG 2.0 conformance
level that is being progressed towards, rather than one already satisfied,
and report the progress on success criteria not yet met. The author of a "Progress
Towards Conformance" Statement is solely responsible for the accuracy
of their statement. Developers are encouraged to provide expected timelines
for meeting outstanding success criteria within the Statement.
Disclaimer
Neither W3C, WAI, nor 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 D: Acknowledgments
Appendix Editors:
- 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 ()
- Ann McMeekin (Invited Expert)
- Sueann Nichols (IBM)
- Greg Pisocky (Adobe)
- Jan Richards (Adaptive Technology Resource Centre, University of Toronto)
- Andrew Ronksley (Royal National Institute for the Blind)
- Roberto Scano (IWA/HWG)
- Jeanne Spellman (W3C)
- Jutta Treviranus (WG Chair; Adaptive Technology Resource Centre, University of Toronto)
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, Charles McCathieNevile, Matt May, Matthias Müller-Prove, Liddy Nevile, Graham Oliver, Wendy Porch, Bob Regan, Chris Ridpath, 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 ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.