This document provides non-normative information to authoring tool developers who wish to satisfy the guidelines in the "Authoring Tool Accessibility Guidelines 2.0" [ATAG20]. It includes suggested techniques, sample strategies in deployed tools, and references to other accessibility resources (such as platform-specific software accessibility guidelines) that provide additional information on how a tool may satisfy each ATAG 2.0 guideline.
The "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative (WAI).
This document is the internal working draft used by the ATAG WG and is updated continuously and without notice. This document has no formal standing within W3C. Please consult the group's home page and the W3C technical reports index for information about the latest publications by this group.
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 1.0 (ATAG 1.0) [ATAG10] is the stable, referenceable version. This Working Draft does not supersede ATAG 1.0.
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 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 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 is a Working Draft of the Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0, a companion document to the Authoring Tool Accessibility Guidelines 2.0 [ATAG20], which provides normative requirements for authoring tools. The purpose of this techniques document is to provides further information on the intent of each ATAG 2.0 success criterion and examples of how each may be applied to real tools. This interpretation represents the best thinking of the Authoring Tool Accessibility Guidelines Working Group (AUWG) and as such is a good guide to achieve conformance to ATAG 2.0. The Working Group encourages authoring tool developers to implement these techniques where appropriate. However, these techniques do not provide a final definition of ATAG 2.0 conformance and it may be possible to meet the guideline requirements without following these techniques and thus this document is informative. As new methods of conforming to the guidelines come to the attention of the Working Group, these techniques will be updated.
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 including two parts, overall principles, general guidelines, testable success criteria and a collection of techniques with examples and resource links.
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).
As with WCAG 2.0, there are a number of conditions that must be met for a Success Criterion to be included in ATAG 2.0. These include:
The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting issues. Some of the common factors evaluated when setting the level in Part A included:
Some of the common factors evaluated when setting the level in Part B included:
When implementing ATAG 2.0, it is recommended that authoring tool developers closely integrate features that support accessible authoring with the "look-and-feel" of other features of the authoring tool. Close integration has the potential to:
Rationale: When authoring tools or parts of authoring tools (e.g., an online help system) are web-based, conforming to WCAG 2.0 will facilitate access by all authors, including those using assistive technologies.
Rationale: When authoring tools or parts of authoring tools are non-web-based (e.g., a client-side file uploader for a web-based content management system), following existing accessibility standards and/or platform conventions that support accessibility will facilitate access by all authors, including those using assistive technologies.
A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow (and cite in the conformance claim) accessibility standards and/or platform conventions that support accessibility. (Level A)
A.2.1.1 Recognized Alternative Content: When recognized alternative content is available for web content being edited, the authoring tool makes the alternative content accessible to the author(s). (Level A)
Rationale: Some authors need access to the editing view presentation because this may be used to convey both status information added by the authoring tool (e.g., underlining misspelled words) and, within content renderings, information about the end user experience of the web content being edited.
A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of web content to provide additional information, then that additional information can be programmatically determined. (Level A)
delare used, since these have semantic meaning.
A.2.2.2 Access to Text Presentation (Minimum): If an editing view (e.g., WYSIWYG view) renders any of the following presentation properties for text, then the properties can be programmatically determined: (Level A)
A.2.2.3 Access to Text Presentation (Enhanced): If an editing view (e.g., WYSIWYG view) renders any presentation properties for text, then the properties can be programmatically determined. (Level AAA)
A.2.3.1 Independence of Display: The author(s) have the global option to specify display settings for editing views that take precedence over web content renderings without affecting the web content to be published. (Level A)
Rationale: Some authors with limited mobility or visual disabilities are not able to use a mouse, and instead require full keyboard access.
A.3.1.1 Keyboard: 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 author's movement and not just the endpoints. (Level A)
Note 1: The movement 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.
Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
A.3.1.3 Keyboard Shortcuts: The authoring tool provides keyboard shortcuts. (Level AA)
Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or requiring a fast reaction speed, such as clicking on a moving target.
A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to a time limit (e.g., an authenticated session expires), then the author(s) have the global option to ensure that the web content being edited is saved. (Level A)
Note: For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent.
A.3.2.2 Timing Adjustable: For each time limit that is set by the authoring tool, at least one of the following is true: (Level A)
Rationale: Flashing can cause seizures in authors with photosensitive seizure disorder.
A.3.3.1 Static View Option: If an editing view renders time-based content (e.g., animations), the author(s) have the global option of rendering only the initial state of time-based web content. (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 the tasks of navigation and editing the content.
A.3.4.1 Edit by Structure: If an editing view displays a structured element set, then the author(s) can select any element in the structured element set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements. (Level A)
<table>element is selected and the "delete" operation is performed, the entire table is deleted including sub-elements (
td) and any text content etc. within the table.
A.3.4.2 Navigate By Element Type: If an editing view displays a structured element set, then the author(s) can move the editing focus forward or backward to the next instance of the same element. (Level AA)
h6. When a searched-for header element exists, it is selected in the editing view, enabling authors to immediately edit the element.
A.3.4.4 Navigate Tree Structures: If an editing view displays a structured element set, then the author(s) can move the editing focus from any element to the following other elements in the structured element set (if they exist): (Level AA)
Rationale: 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).
A.3.6.2 Multiple Sets: Choosing between multiple sets of preferences (e.g., personal profiles, personal settings) are supported for any of the following that the authoring tool controls (i.e., not controlled by the platform): (Level AAA)
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 to be able to follow the same workflow.
A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (Level A)
Rationale: Some authors who have difficulty making fine movements may be prone to making unintended actions.
A.4.1.1 Undo Content Changes:
Authoring actions are either reversible
by an "undo" function or include a warning to authors that the action is
irreversible. (Level A)
Note 1: It is acceptable to collect text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action.
A.4.1.3 Redo: Authors can immediately reverse the most recent "undo" action(s) (i.e., a "redo" function). (Level AA)
Rationale: For the purposes of this document, WCAG 2.0 defines the accessible web content requirements. To support accessible web content production, at minimum, it must be possible to produce web content that complies to WCAG 2.0 using the authoring tool.
B.1.2.1 End Product Preserves Accessibility Information: If the web content technology of the output of a transformation or conversion can preserve recognized accessibility information that is required for that web content to conform to WCAG 2.0 Level A, then the accessibility information is preserved and available for end users in the end product of the transformation or conversion. (Level A)
B.1.2.2 End Product Cannot Preserve Accessibility Information: If the web content technology of the output of a transformation or conversion cannot preserve recognized accessibility information that is required for the end product of the transformation or conversion to conform to WCAG 2.0 Level A, then at least one of the following are true: (Level A)
B.1.2.3 Accessibility Information Preservation (Enhanced): If the authoring tool performs transformations or conversions during an authoring session, then any accessibility information in the pre-transformation/conversion content that is required for the end product of the transformation or conversion to conform to WCAG 2.0 Level AA or AAA is preserved and available for end users. (Level AA)
See Also: If accessibility information is required from authors during the automatic generation process, see Guideline B.2.1. If templates or other pre-authored content are involved, see Guideline B.2.5.
B.1.3.1 Automatic Accessible (Level A): If the authoring tool automatically generates content, then that web content meets WCAG 2.0 Level A prior to publishing. (Level A)
Note 1: This success criterion (as well as B.1.3.2 and B.1.3.3) applies to the automated behavior specified by the authoring tool developer only when author(s) respond properly to any prompts.
Note 2: This success criterion (as well as B.1.3.2 and B.1.3.3) does not apply when actions of the author(s) prevent generation of accessible web content (e.g., the author(s) might set less strict preferences, ignore prompts for accessibility information, provide faulty accessibility information, write their own automated scripts, etc.).
B.2.1.X Decision Support: If the authoring tool presents choices to the author(s), provide information to assist the author in making choices that enable the content to conform to WCAG 2.0. (Level A) @@decision-support SC@@
B.2.1.1 Set Accessible Properties: Mechanisms that set the properties of web content (e.g., attribute values, etc.) include the ability to set the accessibility-related properties. (Level A)
B.2.1.2 Other Technologies: If the authoring tool enables web content to be inserted that the authoring tool cannot be used to edit, then provide the author(s) with the option to insert or associate accessibility information. (Level A)
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.
See also: For more information on checking, see ATAG 2.0 Techniques - Appendix B: Levels of Checking Automation.
B.2.2.1 Check Accessibility (Level A): At least one individual check
is associated with each WCAG 2.0 Level A Success Criterion that the authoring tool has the functionality to modify web content to meet (e.g., an HTML authoring tool that inserts images should check for alt text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A)
Note: While automated checking or more advanced implementations of semi-automated checking may improve the authoring experience, manual checking is the minimum requirement to meet this success criterion (as well as B.2.2.4 and B.2.2.10).
B.2.2.3 Help Authors Decide: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided to help authors to decide whether it is correctly identified. (Level A)
B.2.2.4 Help Authors Locate: For any checks that require author judgment to determine whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant web content is identified (e.g., displaying the web content, displaying line numbers, etc.) (Level AA)
B.2.2.5 Check Accessibility (Level AA): At least one individual check is associated with each WCAG 2.0 Level AA Success Criterion that the authoring tool has the functionality to modify web content to meet. (Level AA)
B.2.2.6 View Status: If the authoring tool records web content accessibility problems found during checking, then a list of any problems is available to authors prior to the end of the authoring session. (Level AA)
B.2.2.7 Save Status for Repair: If repair assistance is not provided during checking, then authors have the option to save a list of web content accessibility problems to facilitate interoperability between checking and repair. (Level AA)
B.2.2.8 Metadata for Discovery: If the authoring tool records the accessibility status of web content, then authors have the option to associate this status with the web content as metadata to facilitate resource discovery by end users. (Level AA)
B.2.2.9 Metadata for Repair: If repair assistance is not provided during checking, then authors have the option to save a metadata listing of the web content accessibility problems to facilitate interoperability between checking and repair. (Level AAA)
B.2.2.10 Check Accessibility (Level AAA): At least one individual check is associated with each WCAG 2.0 Level AAA Success Criterion that the authoring tool has the functionality to modify web content to meet. (Level AAA)
See also: For more information on repair , see ATAG 2.0 Techniques - Appendix C: Levels of Repair Automation.
B.2.3.1 Repair Accessibility (Level A): For each WCAG 2.0 Level A web content accessibility problem that is identifiable during checking (required
in Guideline B.2.2), repair assistance is provided. (Level A)
Note: While automated repair assistance or more advanced implementations of semi-automated repair assistance may improve the authoring experience, manual repair assistance is the minimum requirement to meet this success criterion (as well as success criteria B.2.3.2 and B.2.3.3).
B.2.3.2 Repair Accessibility (AA): For each WCAG 2.0 Level AA web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level AA)
B.2.3.3 Repair Accessibility (AAA): For each WCAG 2.0 Level AAA web content accessibility problem that is identifiable during checking (required in Guideline B.2.2), repair assistance is provided. (Level AAA)
See also: This guideline applies when non-text content is specified by the author(s) (e.g., an author inserts an image). When non-text content is automatically added by the authoring tool, see Guideline B.1.3.
B.2.4.1 Editable: Authors are able to modify alternative content for non-text content. This includes types of alternative content that may not typically be displayed on screen by user agents. (Level A)
longdesc), then that resource can be opened for editing.
B.2.4.3 Let user agents repair: After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text value that is equally available to user agents (e.g., the filename is not used). (Level A)
B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)
B.2.5.1 Templates "A" Accessible: If the authoring tool automatically selects templates or pre-authored content, then the selection meets WCAG 2.0 Level A when used. (Level A)
Note: Templates may be complicated to check for accessibility due to their inherent incompleteness. The accessibility status of templates is instead measured by the accessibility of web content (in the final web content technology) created when authors use them properly.
B.2.5.5 New Templates: If authors can use the authoring tool to create new templates for use by a template selection mechanism, they have the option to record the accessibility status of the new templates. (Level AA)
B.2.5.6 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.8 Pre-Authored Content in Repository: If the authoring tool provides a repository of pre-authored content, then each of the content objects has a recorded accessibility status. (Level AAA)
Rationale: When authors are learning a new authoring tool, they may find and learn to use the first authoring action they encounter that achieves their intended outcome. Since they may be unaware of the issue of accessibility, it is preferable that accessible web content be an additional unintended outcome, rather than inaccessible content.
B.3.1.1 Accessible Options Prominent (Level A): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level A are at least as prominent as options that will not. (Level A)
font. Since using CSS is the more accessible option, it is given a higher prominence within the authoring interface by: (1) the "CSS Styling" option appearing above the "FONT Styling" option in the drop down Text menu, and (2) the CSS styling option being used to implement the one-click text color formatting button in the tool bar. The association is made clear because the toolbar button has the same icon (an "A" beside a color spectrum) as the "Color" sub-menu item under the "CSS Styling" menu option.). An (Source: mockup by AUWG)
B.3.1.2 Accessible Options Prominent (Level AA): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level AA are at least as prominent as options that will not. (Level AA)
B.3.1.3 Accessible Options Prominent (Level AAA): If the author(s) are provided with multiple options for an authoring task, options that will result in web content conforming to WCAG 2.0 Level AAA are at least as prominent as options that will not. (Level AAA)
B.3.2.1 Active by Default: All accessible content support features are turned on by default. (Level A)
B.3.2.3 Deactivation Warning: If the author(s) deactivate an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA)
B.3.2.4 At Least as Prominent: Accessible content support features are at least as prominent as comparable features related to other types of web content problems (e.g., invalid markup, syntax errors, spelling and grammar errors). (Level AA)
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.
Rationale: Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors.
B.3.4.1 Model Accessible Practice (Minimum): A range of examples of documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)
B.3.4.2 Model "AA" Accessible Practice (Enhanced): A range of examples of documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level AA accessible authoring practices. (Level AA)
The relationship is as follows:
"Partial" ATAG 2.0 Conformance: Authoring Tool User Interface: This type of conformance claim 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: Content Production:This type of conformance claim 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):
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.
A conformance claim is an assertion by a Claimant that an authoring tool has satisfied the requirements of ATAG 2.0 under the conditions described.
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.
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 informative.
In order to produce accessible web content, authoring tools often need authors to provide accessibility information such as text alternatives for images, role and state information for widgets, relationships within complex tables, captions for audio. As for any information to be gathered from the author, there are a range of approaches that a developer might take for gathering accessibility information, from voluntary unintrusive reminders to intrusive mandatory prompts. While ATAG 2.0 does not require any particular approach, author cooperation and goodwill are important considerations in ensuring that the accessibility information that is gathered is correct and complete.
The following is a discussion of some of the considerations when gathering different types of accessibility information, along with some example implementations.
@@it would be great to get some more ARIA style examples in here@@
Example A-1a: A dialog box offers short text labels for reuse. It shows an "Insert Image" dialog box a thumbnail image of the "earthrise" graphic along with entry fields for "src", "alt", "longdesc", "height" and "width". The "alt" entry field is drop-down list that is shown with several short labels for the same image. The first is a visual description in English ("An earth rise as seen from the moon"), the second is a visual description in French ("Une vue do la terre de la lune") and the third is an English functional label used if the image serves as a link ("Go to pictures of the earth"). (Source: mockup by AUWG)
Example A-1b: A source content editing view offers short text labels for reuse. It shows the author midway through adding markup for an image. After adding the
srcattribute value the author has pressed the spacebar, causing the tool to prompt them with the
altattribute along with several attribute values, including a visual description in English (alt="An earth rise as seen from the moon"), a visual description in French (alt="Une vue de la terre de la lune") and an English functional label used if the image serves as a link (alt="Go to pictures of the earth"). (Source: mockup by AUWG)
Example A-2: An interface for image map area text labels. It is comprised of a list with two columns. In the right-hand column is the URL for each image map area. This can be used as a hint by the author as they fill in the text labels (left-hand column). A checkbox at the bottom provides the option of using the text labels to create a set of text links below the image map. (Source: mockup by AUWG)
Example A-3: An interface for long text descriptions. A "description required" checkbox controls whether the rest of the interface is available. If a description is required, the author then has the choice of opening an existing description file or writing (and saving) a new one. If they choose to use an existing file, there is a text entry area for the name along with a button to browse the file system. If they choose to compose a new description, there is a text entry area for the description followed by a text field for the file name and a button to save it to that location. In the situation shown, the author chooses to use an existing description of "earthrise" so the file name containing the description is shown. In addition, the text of the description from the file is loaded into the compose area ("The earth hangs in the pitch black sky above the gray horizon of the moon. The dazzling blue sphere is covered with creamy white streamers of cloud.") in case the author would like to use this text as a basis for a new description. (Source: mockup by AUWG)
Example A-4: A form properties list with five columns that allows the author to simultaneously decide the following for each field: the tab order, form name, field label, control type, and accesskey. In this example, two form field labels are missing, causing yellow highlighting of the cells and red icons to be displayed. "Move up" and "move down" buttons are provided. (Source: mockup by AUWG)
Example A-7: A source content editing view that suggests access key values. The following markup can be seen: "
<body><p>Here is one of the most famous photographs taken from the <a href="moon.html" > moon.</a></p><It was taken with a special <a href=camera.html" accesskey="c">camera.</p>". A pop-up menu, centered on the word "moon" suggest accesskey="m", because "moon" begins with "m", followed by the rest of the alphabet in order. Accesskey="c" is missing, however, since it is already used as an accesskey later in the document (for the "camera" link). (Source: mockup by AUWG)
Example A-8: A dialog box for choosing sufficiently contrasting color combinations. The dialog box has two tabs: one for text color and one for background color. A "hide low contrast choices" checkbox has been selected, so the palette of colors has been pre-screened so that sufficient contrast between the text and the current background color is assured. All other colors have been grayed out. (Source: mockup by AUWG)
Example A-11: A WYSIWYG editing view that detects opportunities for enhancing structure and alerts the author. On the left side is the WYSIWYG editing view with the title of the page ("Mars") displayed with a blue underline. The author has brought up a pop-up menu for the title and sees the following options: "Repair: Mark as heading (a sub-menu displays the different levels of header (i.e., h1, h2, etc.)) for the author to choose", "Skip", "Ignore", "Check Accessibility...", and "Help...". On the right, an element inspector makes clear that the title is currently marked up as a paragraph. (Source: mockup by AUWG)
Example A-12: A WYSIWYG editing view that prompts the author to decide whether the top row of a table contains the table header cells. The top row of the rendered table is outlined in blue to indicate an accessibility problem. The author has brought up a pop-up menu for one of the cells in the top row and sees the following options: "Repair: Set as header row", "Skip", "Ignore", "Check Accessibility...", and "Help...". (Source: mockup by AUWG)
Example A-14a: A source content editing view that indicates the reading level of a page and whether it exceeds a limit determined by the author's preference settings. The editing view includes the following markup:
<body><h1>Mars</h1><p>Mars is the fourth planet in the solar system, orbiting at a distance of 1.5 AU, with a period of 687 days.</p></body></html>. Then in a status bar below the text entry area, is a reading level display: "Reading Level: 11.2 (target<8)". The 11.2 is highlighted with a yellow background and bold text to indicate that the target is exceeded. (Source: mockup by AUWG)
Example A-14b: An authoring interface that prompts the author to enter an acronym expansion. The rendered text reads: "The 'habitable zone' around a star is the region of that star’s solar system in which liquid water is possible. The continuous habitable zone (CHZ) is the region of the solar system which has remained in the zone, even during changes in the star’s radiation pattern." The acronym "CHZ" is identified with a blue underline as an accessibility problem. The author has brought up a pop-up menu for the acronym and sees the following options: "Repair: Enter acronym expansion…", "Check Accessibility...", and "Help...". (Source: mockup by AUWG)
onactivate[DOM]) instead of device-specific events (e.g.,
onclick), or route multiple events (
onkeypress) through the same functions.
onfocusevent to elements that are targeted with the
ondblclick) and avoid these events as default options.
Example A-16: An authoring interface for prompting the author about whether a paragraph that contains many numbers might be made more clear with the addition of a chart or graph. On the left side of the interface is the rendered text: " Planet Orbits: The inner planets orbit the sun relatively quickly with Mercury orbiting the sun in 88 days, Venus in 224 days, Earth in 365 days, and Mars in 687 days. Compare this to Jupiter’s, 4332 day orbit." This text is marked with a yellow exclamation mark icon. On the right side is the following explanation of the error icon: "This paragraph contains 5 numbers. Would readers benefit if a chart or graph of this information was added?". "Yes" and "no" buttons are provided. (Source: mockup by AUWG)
This section is informative.
This list is representative, but not necessarily complete.
In automated checking, the tool is able to check for accessibility problems automatically, with no human intervention required. This type of check is usually appropriate for checks of a syntactic nature, such as the use of deprecated elements or a missing attribute, in which the meaning of text or images does not play a role.
Example B-1: A summary interface for a code-based authoring tool that displays the results of an automated check. The display is a tree-view where the leftmost nodes are the names of problems ("Image missing alternate text" and "Text boxes missing labels) with number of problems appended (e.g., "") and the sub-items are the problem instances with line numbers appended (e.g., "(Line:45)"). (Source: mockup by AUWG)
Example B-2: A WYSIWYG interface that displays the results of an automated check in a WYSIWYG authoring view using blue highlighting around or under rendered elements (in this case, the "earthrise" image and some "blinking text"), identifying accessibility problems for the author to correct. (Source: mockup by AUWG)
Example B-3: An authoring interface of an automated check in a instruction-level authoring view. The text is: "
<body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>".In this view, the text of elements with accessibility problems (
blink) is shown in a blue font, instead of the default black font. (Source: mockup by AUWG)
In semi-automated checking, the tool is able to identify potential problems, but still requires human judgment by the author to make a final decision on whether an actual problem exists. Semi-automated checks are usually most appropriate for problems that are semantic in nature, such as descriptions of non-text objects, as opposed to purely syntactic problems, such as missing attributes, that lend themselves more readily to full automation.
Example B-4: A dialog box that appears once the tool has detected an image without a description attribute. However, since not all images require description, the author is prompted to make the final decision ("Does this image require descriptive text?"). The author can confirm the at this is indeed an accessibility problem by choosing and move on to the repair stage by choosing "Yes" or press "No" to mark the potential problem, as not a problem at all. Additional help is available in the form of a tip: "An image requires descriptive text when the information it contains cannot be conveyed in 10 words or less using an alternate text label." (Source: mockup by AUWG)
In manual checking, the tool provides the author with instructions for detecting a problem, but does not automate the task of detecting the problem in any meaningful way. As a result, the author must decide on their own whether or not a problem exists. Manual checks are discouraged because they are prone to human error, especially when the type of problem in question may be easily detected by a more automated utility, such as an element missing a particular attribute.
Example B-5: A dialog box that reminds the author to check if there are any words in other languages in the document with the message: "Does this document contain any words or phrases in a different language than the main content?". The author can move on to the repair stage by pressing "Yes" or press "No" to mark the potential problem, as not a problem at all. (Source: mockup by AUWG)
This section is informative.
This list is representative, but not necessarily complete.
In manual repairing, the tool provides the author with instructions for making the necessary correction, but does not automate the task in any substantial way. For example, the tool may move the cursor to start of the problem, but since this is not a substantial automation, the repair would still be considered "manual". Manual correction tools leave it up to the author to follow the instructions and make the repair by themselves. This is the most time consuming option for authors and allows the most opportunity for human error.
Example C-1: Repair instructions in a code level editing view. In this case, the following markup is being edited:
<body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>. Since the problems have already been detected in the checking step and the selected offending elements in a code view (
<blink>Blinking text</blink>) have been highlighted in blue text. When the author puts focus on the highlighted text, a short repair instruction ("Repair: Add 'alt' attribute") appears in a status bar with a button than will open a longer explanation in the help system. (Source: mockup by AUWG)
In semi-automated repairing, the tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be complete. For example, the tool may prompt the author for a plain text string, but then be capable of handling all of the markup required to add the text string to the content. In other cases, the tool may be able to narrow the choice of repair options, but still rely on the author to make the final selection. This type of repair is usually appropriate for corrections of a semantic nature.
Example C-2: A semi-automated repair in a WYSIWYG editing view. The author has right-clicked on an image of the "earthrise" that has been highlighted with a blue outline by the automated checker system. This has brought up a pop up menu with the following choices: "Repair: Set Alt -Text: 'An earth rise as seen from the moon'", "Enter different alt-text…", " Skip", "Ignore", "Check Accessibility...", "Help...". The author must decide whether the label text that the tool suggests is appropriate. Whichever option the author chooses, the tool will handle the details of updating the content. (Source: mockup by AUWG)
In automated repairing, the tool is able to make repairs automatically, with no author input required. For example, a tool may be capable of automatically adding a document type to the header of a file that lacks this information. In these cases, very little, if any, author notification is required. This type of repair is usually appropriate for corrections of a syntactic or repetitive nature.
Example C-3: An announcement that an automated repair has been completed ("All instances of <blink> have been replaced with CSS styling according to your preferences."). The author selects an "ok" to proceed. An "undo" button is provided in case the author wishes to reverse the operation. In some cases, automated repairs might be completed with no author notification at all. (Source: mockup by AUWG)
This section is informative.
This list is representative, but not necessarily complete.
(a) Negotiated Interruption: A negotiated interruption is caused by interface mechanisms (e.g., icons or highlighting of the element, audio feedback) that alert the author to a problem, but remain flexible enough to allow the author to decide whether to take immediate action or address the issue at a later time. Since negotiated interruptions are less intrusive than immediate or scheduled interruptions, they can often be better integrated into the design workflow and have the added benefit of informing the author about the distribution of problems within the document. Although some authors may choose to ignore the alerts completely, it is not recommended that authors be forced to fix problems as they occur. Instead, it is recommended that negotiated interruption be supplemented by scheduled interruptions at major editing events (e.g., when publishing), when the tool should alert the author to the outstanding accessibility problems.
Example D-1: A WYSIWYG editing view makes the author of problems detected automatically by means of a blue line under text or around rendered objects with accessibility problems. Here, red lines are also visible, highlighting spelling errors in the text. The author can decide to address the problems at a later time. (Source: mockup by AUWG)
(b) Scheduled Interruption: A scheduled interruption is one in which the author has set the tool to alert them of accessibility issues on a configurable schedule. One option for the schedule might be to have prompts associated with the interface mechanisms for significant authoring events, such as opening, saving, closing, committing, or publishing files. At the significant authoring event, the author would be informed of the problem, while at the same time they would not be prevented from saving, publishing, printing, etc. A potential downside of postponing corrective actions is that by the time the prompt is displayed, the author may not have sufficient time or inclination to make the required changes, especially if they are extensive.
Example D-2: A "Publish" dialog box allows the author to publish multiple files at once, however in the case shown here, two of the files have uncorrected accessibility problems which causes them not to meet a "standard of publishing" the author has set for themselves in the options. As a result the files are selected, a message is displayed ("The selected files do not meet your specified standard for publishing.") and the "publishing" button is grayed out. This standard is referred to generally since it is assumed that it might include spelling and grammar standards as well as accessibility issues. (Source: mockup by AUWG)
(c) Immediate Interruption: An immediate interruption is the most intrusive timing option because the attention of the author is actively diverted from the current editing task by the notification of some issue. This might be achieved, for instance, by an alert dialog. This type of alert presents multiple usability problems and should be used sparingly because it interferes with the normal design workflow. Intrusive warnings are probably only appropriate when the window of opportunity for correcting a serious accessibility problem is about to close, such as when an author decides to publish the content in question. In general, negotiated and scheduled interruptions are preferred.
Example D-3: A modal dialog box contains the message: "This image is missing alternate text". The author must press the "OK" button to continue. (Source: mockup by AUWG)
This section is informative.
Dealing flexibly with real-time content production. When authoring tools produce content in real time, it is usually no longer possible to delay addressing accessibility problems until an arbitrary point in the future. At the same time, due to the time pressure, authors in real-time environments tend to be less receptive to intrusive prompts. Nevertheless, tools that allow this kind of authoring should still take accessibility issues into account by supporting the following:
(a) Determination of Participant Requirements: If real-time authoring is consumed by individuals with no special communicative needs, there may be no need for real-time prompting. However, as with any other web content it is often impossible for the author to know all of the needs of the actual or potential participants. Therefore, the best practice is to create real-time content that conforms with WCAG to the greatest extent possible. However, when this is not possible, a real-time authoring tool might be able to facilitate graceful degradation of accessibility by polling the participants (see "Request whiteboard descriptions" checkbox in the figure) or in some cases checking the profiles of participants (e.g., using CCPP, ACCLIP) to determine which types of accessibility practices would offer the greatest advantage in the short time available. Once this information is compiled, the tool can prompt the author (or see Assistant/Peer Author) to correct problems appropriately (preferably during Preparation Time). When it is not possible to know, with certainty, the needs of all participants, the tool should still assume that accessible content is required. This is especially true if the results of the session will be archived.
(b) Assistant/Peer Author: In some cases, it may be possible to designate one or more secondary authors in the live community, who can receive and respond to prompts for supplemental information generated as the primary author proceeds uninterrupted. The secondary author might be an unrelated specialist, analogous to Sign language interpreter, a co-author (helpful for describing technical drawings, etc.), or in some situations any member of the session audience (i.e., a peer).
(c) Preparation Time: If the authoring tool allows the author time to pre-assemble materials for a live presentation (e.g., a professor preparing for an online class), this authoring is not considered real-time authoring. The authoring tool has the opportunity and the obligation to support accessible authoring as described elsewhere in this document.
(d) Archiving: If the session will be archived, there may be other opportunities to increase the accessibility of the content of the archive by guiding the author through a process to check for and repair accessibility problems after the real-time session has ended, but prior to archiving.
If it has been determined that the author must provide real-time supplements, but no preparation time or assistant author are available, then in addition to allowing the author control of the nature and timing of prompting, the authoring tool can facilitate the inclusion of supplements by:
Example E-1: A real-time presentation in a whiteboard/chat client environment that has been enhanced to provide real-time descriptions. The example has five panes. On the far left is a list of participants ("Presenter", "John (You)", "Jane", and "Alice"). In the upper-middle is the chat "Presenter> I suggest a space theme for the slide presentation.", "Image File Inserted (by Presenter) Description: An earthrise as seen from the surface of the moon.", "Presenter> The white text would go...", "Marker (by Presenter) Description> Draws a red box..., and "Presenter> in this area." Notice that descriptions are appearing here. The lower-middle is the message composition area for this user and is blank. The upper-right is the whiteboard. So far there is an image of "earthrise" and a red hand-drawn rectangle on the "canvas". The whiteboard tools are "select box", "text tool", "marker", "eraser", "insert image", "line tool", "rectangle tool", and an "ellipse tool". In the lower-right is an area for describing a drawing action - in this case the "Presenter' use of the Marker". Notice that any participant can describe the events on the whiteboard even as the dialog continues. (Source: mockup by AUWG).
This section is informative.
For the latest version of any W3C specification please consult the list of W3C Technical Reports at http://www.w3.org/TR/. Some documents listed below may have been superseded since the publication of this document.
Note: In this document, bracketed labels such as "[WCAG20]" link to the corresponding entries in this section. These labels are also identified as references through markup.
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, 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.