[Table of Contents] | [Implementing ATAG 2.0]
Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This standard provides guidelines for designing web content authoring tools that are both more accessible to authors with disabilities (Part A) and designed to enable, support, and promote the production of more accessible web content by all authors (Part B). See Authoring Tool Accessibility Guidelines (ATAG) Overview for an introduction and links to ATAG technical and educational material.
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/.
This is an updated Candidate Recommendation of Authoring Tool Accessibility Guidelines (ATAG) 2.0 from the Authoring Tool Accessibility Guidelines Working Group. This version simplifies the exit criteria to bring them more in line with current W3C practices, removes items at risk, and integrates minor editorial changes identified since the publication of the original 7 November 2013 Candidate Recommendation. The change to the exit criteria removes the requirements for authoring tools to meet all applicable success criteria at A and AA. There are no longer any features at risk.
A Candidate Recommendation is a document that has been widely reviewed and is ready for implementation. Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. Before the specification can progress to Proposed Recommendation, the CR exit criteria must be met.
Besides these implementations, feedback on implementation and use of this specification is welcome, including from implementations not selected as part of the formal implementation report for exiting Candidate Recommendation. Comments should be sent to public-atag2-comments@w3.org (Public Archive).
ATAG WG has already performed extensive testing during the first part of the Candidate Recommendation period. While the vetting process is not yet complete, the preliminary implementation report (requires W3C login) shows that we have two implementations of each of the ATAG success criteria. With these simplified exit criteria, ATAG WG expects to show evidence of meeting the exit criteria no earlier than 2 July 2015.
For this specification to be advanced to Proposed Recommendation, there must be at least two independent implementations of features that meet each success criterion. Each of these features may be implemented by a different set of products and there is no requirement that all features be implemented by a single product.
Independent authoring tools
are tools by different developers that do not share (or derive from) the same source code for the relevant feature(s). Sections of code that have no bearing on the implementation of this standard are exempt from this requirement. The authoring tools must be a shipping product or other publicly available version. Experimental implementations, specifically designed to pass the test suite and not intended for normal usage, are not permitted.
Implemented
refers to situations in which a success criterion is applicable to a given authoring tool and the authoring tool meets the success criterion. This is in contrast to situations in which a success criterion is not applicable.
Success criteria referencing WCAG 2.0 for priorities
For the thirteen ATAG 2.0 success criteria that are dependent on WCAG 2.0 for their levels, each ATAG 2.0 success criterion must be implemented for two WCAG 2.0 success criteria at each level: A, AA, and AAA. These six WCAG 2.0 success criteria are a sampling of the requirements of WCAG (e.g. text alternatives for non-text content, keyboard accessibility, sufficient contrast).
As a part of the Candidate Recommendation process, any items that might change or where there may not be implementations are marked as "at risk." "At risk" in no way implies that these success criteria are less important to accessibility. It is a W3C requirement to identify any provision for which the Working Group believes it may not be able to document the required implementations by the end of the Candidate Recommendation period.
There are no features at risk.
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.
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.
Publication as a Candidate Recommendation 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 document is governed by the 1 August 2014 W3C Process Document.
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 auditory, cognitive, neurological, physical, speech, and visual disabilities.
Authoring tool accessibility addresses 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, he (or she) 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 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 these audiences, several layers of guidance are provided:
See Authoring Tool Accessibility Guidelines (ATAG) Overview for links to additional ATAG technical and educational material.
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.
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:
The success criteria and the conformance applicability notes in this section are normative.
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.
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)
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.
If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces follow user interface accessibility guidelines for the platform. (Level A)
If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services. (Level A)
Rationale: Some authors require access to alternative content in order to interact with the web content that they are editing.
If an editing-view renders non-text content, then any programmatically associated text alternatives for the non-text content can be programmatically determined. (Level A)
If an editing-view renders time-based media, then at least one of the following is true: (Level A)
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.
If an editing-view adds status indicators to the content being edited, then the information being conveyed by the status indicators can be programmatically determined. (Level A)
If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined. (Level AA)
Rationale: Some authors with limited mobility or visual disabilities do not use a mouse and instead require keyboard interface access to all of the functionality of the authoring tool.
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)
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. 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)
The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA)
All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)
If the authoring tool includes keyboard commands, then those keyboard commands can be customized. (Level AAA)
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)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.
The authoring tool does not include session time limits or the authoring tool can automatically save edits made before the session time limits are reached. (Level A)
The authoring tool does not include time limits or at least one of the following is true: (Level A)
The authoring tool does not include moving user interface components that accept input where the movement of these components cannot be paused by authors. (Level A)
The authoring tool can be set to automatically save web content edits made using the authoring tool. (Level AAA)
Rationale: Flashing can cause seizures in authors with photosensitive seizure disorder.
If an editing-view can play visual time-based content, then playing is not necessarily automatic upon loading the content and playing can be paused. (Level A)
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.
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)
If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. (Level AAA)
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.
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)
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).
If the authoring tool includes display settings for editing-views, then the authoring tool allows authors to adjust these settings without modifying the web content being edited. (Level A)
If the authoring tool includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA)
The authoring tool respects changes in platform display and control settings, unless authors select more specific display and control settings using the authoring tool. (Level AA)
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.
If a preview is provided, then at least one of the following is true: (Level A)
If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA)
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.
All authoring actions are either reversible or the authoring tool requires author confirmation to proceed. (Level A)
If the authoring tool provides mechanisms for changing authoring tool user interface settings, then those mechanisms can reverse the setting changes, or the authoring tool requires author confirmation to proceed. (Level A)
Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)
Rationale: Some authors may not be able to understand or operate the authoring tool user interface without documentation.
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)
For each authoring tool feature, at least one of the following is true: (Level AA)
Rationale: If authoring tools automatically produce web content that includes accessibility problems (WCAG), then this will impose additional repair tasks on authors.
The authoring tool does not automatically generate web content after the end of an authoring session, or, 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)
Rationale: Accessibility information (WCAG) is critical to maintaining comparable levels of web content accessibility (WCAG) between the input and output of web content transformations.
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)
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 and the source and destination use the same web content technology. (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)
If the authoring tool provides optimizing web content transformations, then any accessibility information (WCAG) in the input is preserved in the output. (Level A).
If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output. (Level A).
Rationale: To support accessible web content (WCAG) production, at minimum, it is possible to produce web content that conforms with WCAG 2.0 using the authoring tool.
The authoring tool does not place restrictions on the web content that authors can specify or 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)
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.
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)
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)
Rationale: Improperly generated alternative content can create web content accessibility problems (WCAG) and interfere with accessibility checking.
Note: This guideline only 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.
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)
The authoring tool does not attempt to repair text alternatives for non-text content or the following are all true: (Level A)
If the authoring tool provides the functionality for adding non-text content,
when authors enter programmatically associated text alternatives for non-text content, then both of the following are true: (Level AAA)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).
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)
If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)
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)
If the authoring tool provides templates, then all of the templates are accessible template (to WCAG Level AA). (Level AAA)
Rationale: Providing accessible pre-authored content (WCAG) (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 accessibility.
If the authoring tool provides pre-authored content, then a range of accessible pre-authored content (to WCAG Level AA) options are provided. (Level AA)
If the authoring tool includes a pre-authored content selection mechanism and provides any non-accessible pre-authored content (WCAG Level AA) options, then the selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)
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.
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)
If the authoring tool provides accessibility checking that relies on authors to decide whether potential web content accessibility problems (WCAG) are correctly identified (i.e. manual checking and semi-automated checking), then the accessibility checking process provides instructions that describe how to decide. (Level A)
If the authoring tool provides checks that require authors to decide whether a potential web content accessibility problem (WCAG) is correctly identified (i.e. manual checking and semi-automated checking), then the relevant content is identified to the authors. (Level A)
If the authoring tool provides checks, then authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA)
If the authoring tool provides checks, then the authoring tool can programmatically associate accessibility checking results with the web content that was checked. (Level AA)
Rationale: When repair is 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.
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)
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.
All accessible content support features are turned on by default. (Level A)
The authoring tool does not include the option to turn off its accessible content support features or features which have been turned off can be turned back on. (Level A)
The authoring tool does not include the option to turn off its accessible content support features or, if these features can be turned off, authors are informed that this may increase the risk of content accessibility problems (WCAG). (Level AA)
All accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA)
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.
A range of examples in the documentation (e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices (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)
Instructions for using any accessible content support features appear in the documentation. (Level A)
The authoring tool provides a tutorial for an accessible authoring process that is specific to that authoring tool. (Level AAA)
The authoring tool documentation contains an index to the instructions for using any accessible content support features. (Level AAA)
This section is normative.
Conformance means that the authoring tool satisfies the applicable success criteria defined in the guidelines section. This conformance section describes conformance and lists the conformance requirements.
The first step in determining ATAG 2.0 conformance is to assess whether the Success Criteria have been satisfied. The potential answers are:
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:
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", and 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.
There are two types of conformance, each with three levels:
This conformance option may be selected when an authoring tool can be used to produce accessible web content (WCAG) without additional tools or components. The level of conformance is determined as follows:
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.
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.
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.
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, though this is not required.
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 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.
In addition to the required components of a conformance claim above, consider providing additional information to assist authors. Recommended additional information 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.
This section is normative.
This appendix contains definitions for all of the significant/important/unfamiliar terms used in the normative parts of this standard, 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 standards quality.
This section is informative.
For the latest version of any W3C standards 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.
Kynn Bartlett, Giorgio Brajnik, Judy Brewer, Wendy Chisholm, Daniel Dardailler, Geoff Deering, Cherie Ekholm, 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, Sueann Nichols, Graham Oliver, Greg Pisocky, Wendy Porch, Sarah Pulis, Bob Regan, Chris Ridpath, Andrew Ronksley, Gregory Rosmaita, Roberto Scano, 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.
[Contents]