Authoring Tool Accessibility Guidelines 2.0

W3C Working Draft 24 September 2002

This version:

http://www.w3.org/WAI/AU/2002/WD-ATAG20-20020924/

Latest version:

http://www.w3.org/TR/ATAG20/

Previous version:

http://www.w3.org/TR/ATAG-WOMBAT/

Editors:

Jutta Treviranus - ATRC, University of Toronto

Charles McCathieNevile - W3C

Jan Richards - University of Toronto

Matt May - W3C

Copyright ©2002 W3C ^®( MIT , INRIA , Keio), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.

---

Abstract

This specification provides guidelines for Web authoring tool developers. Its purpose is two-fold: to assist developers in designing authoring tools that produce accessible Web content and to assist developers in creating an accessible authoring interface.

Authoring tools can enable, encourage, and assist users ("authors") in the creation of accessible Web content through prompts, alerts, checking and repair functions, help files and automated tools. It is just as important that all people be able to author content as it is for all people to have access to it. The tools used to create this information must therefore be accessible themselves. Adoption of these guidelines will contribute to the proliferation of Web content that can be read by a broader range of readers and authoring tools that can be used by a broader range of authors.

This document is part of a series of accessibility documents published by the W3C Web Accessibility Initiative (WAI).

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is a Public Working Draft of a document which will supersede the W3C Recommendation Authoring Tool Accessibility Guidelines 1.0 [ATAG10]. It has been made available for review by W3C Members and other interested parties, in accordance with W3C Process. It is not endorsed by the W3C or its Members. It is inappropriate to refer to this document other than as a "work in progress".

This document has been produced by the Authoring Tool Accessibility Guidelines Working Group (AUWG) as part of the Web Accessibility Initiative (WAI). The goals of the Working Group are discussed in the AUWG charter. A list of current W3C Recommendations and other technical documents including Working Drafts and Notes can be found at http://www.w3.org/TR/. The AUWG is part of the WAI Technical Activity.

This draft refers to the Web Content Accessibility Guidelines (WCAG) for specification of accessible content and refers non-normatively to the Techniques for Authoring Tool Accessibility [ATAG20-TECHS].

The AUWG expects the ATAG 2.0 to be backwards-compatible with ATAG 1.0, or at most to make only minor changes in requirements. Before this document reaches last call, the Working Group will publish a detailed analysis of the differences in requirements.

The working group maintains an ATAG 2.0 Issues List and a log of changes between successive Working Drafts.

Please send comments about this document to the public mailing list: w3c-wai-au@w3.org (public archives). Please note that this document may contain typographical errors. It was published as soon as possible since review of the content itself is important, although noting typographical errors is also helpful.

For information about the current activities of the working group, please refer to the AUWG home page. This page includes an explanation of the inter-relation of each document as well as minutes and previous drafts.

Table of contents

• Abstract
• Status of this document
• 1. Introduction
  • 1.1 How the Guidelines are organized
  • 1.2 Checkpoint Priorities
  • 1.3 Conformance to these Guidelines
• 2. Guidelines
  • Guideline 1: Ensure that the tool itself is accessible
  • Guideline 2: Ensure that the tool is designed to produce accessible content
  • Guideline 3: Support the author in the production of accessible content
  • Guideline 4: Integrate accessibility solutions into the overall "look and feel"
• 3. Glossary of Terms and Definitions
• 4. Acknowledgments
• 5. References

1.3 How this document is organized

This document contains four guidelines that reflect the goals of accessible authoring tool design:

• Guideline 1: Ensure that the tool itself is accessible
• Guideline 2: Ensure that the tool is designed to produce accessible content
• Guideline 3: Support the author in the production of accessible content
• Guideline 4: Integrate accessibility solutions into the overall "look and feel"

Each guideline includes:

• The guideline number
• The statement of the guideline
• The rationale behind the guideline
• A list of checkpoints

Each checkpoint is intended to be specific enough that it can be verified, while being sufficiently general to allow developers the freedom to use the most appropriate strategies to satisfy it. The checkpoints specify requirements for meeting the guidelines. Each checkpoint includes:

• The checkpoint number
• The statement of the checkpoint
• The priority of the checkpoint
• Checkpoint subtext, including:
  • a brief rationale for the checkpoint
  • a minimum basic functionality requirement that is normative
  • suggested functionality for more advanced implementation (this is optional)
  • references to further information and techniques

A separate document, entitled "Techniques for Authoring Tool Accessibility Guidelines 2.0" [ATAG20-TECHS], provides suggestions and examples of how to achieve the recommendations in this document. Another document [ATAG20-CHECKLIST] lists all checkpoints, ordered by priority, for convenient reference.

Priority 1

The checkpoint is essential.

Priority 2

The checkpoint is important.

Priority 3

The checkpoint is beneficial.

Relative Priority (Level 1, 2, or 3)

The importance of the checkpoint depends on the specific requirements of WCAG and is therefore relative to priorities assigned in those guidelines.

Note: The priority level for each checkpoint has been chosen based on the assumption that the author is a competent, but not necessarily expert, user of the authoring tool, and that the author has little or no knowledge of accessibility. For example, the author is not expected to have read all of the documentation, but is expected to know how to turn to the documentation for assistance.

An ATAG conformance claim for an authoring tool must indicate which of the following conformance levels has been met:

Conformance Level "A"

Tool has met all Priority 1 checkpoints and has also met all Relative Priority checkpoints to at least Level 1.

Conformance Level "Double-A"

Tool has met all Priority 1 and 2 checkpoints and has also met all Relative Priority checkpoints to at least Level 2.

Conformance Level "Triple-A"

Tool has met all checkpoints and has also met all Relative Priority checkpoints to Level 3.

For the purposes of ATAG 2.0 conformance claims, tools may be bundled together (e.g. a markup editor and a evaluation and repair tool or a multimedia editor with a custom plug-in), however, this has two important consequences:

1. The bundled tools must be distributed together in order for each to maintain that conformance claim.
2. Bundled tools may have more difficult meeting the checkpoints in Guideline 4 (Integrate accessibility solutions into the overall "look and feel") than single tools that integrate accessibility functionality more tightly.

Conformance Icons: There are currently no conformance icons available for this draft specification. If it becomes a recommendation it is expected that there will be conformance icons like those available for ATAG 1.0.

1.6 Accessible authoring processes

From the standpoint of accessibility, Web authoring is a process that may involve one or more tools in parallel or in sequence. In order to ensure that the Web content produced as a result of a Web authoring process is accessible, developers and purchasers should choose tools that are either ATAG 2.0 conformant or ATAG 2.0-"Friendly". ATAG-"Friendly" tools are tools which, although they do not conform with ATAG, are also very unlikely to degrade the accessibility of Web content. For example, a tool which converts the URI locations in a Web page from absolute to relative prior to publishing.

In some cases, strategic ordering of the tools in a Web authoring process may increase the likelihood of producing accessible content. For example, a markup editor that does not conform to ATAG might be used before an ATAG conformant evaluation and repair tool. While this is, of course, preferable to not addressing accessibility at all, the original markup tool is still considered ATAG non-conformant. Considering the markup editor and evaluation and repair tool together is possible, but due to the low likelihood of proper integration between the tools, the result is unlikely to be a high ATAG conformance level.

2. Guidelines

GUIDELINE 1: Ensure that the tool itself is accessible

The authoring tool is a software program with standard user interface elements and as such must be designed according to relevant user interface accessibility guidelines. When custom interface components are created, it is essential that they be accessible through the standard access mechanisms for the relevant platform so that assistive technologies can be used with them.

Some additional user interface design considerations apply specifically to Web authoring tools. For instance, authoring tools must ensure that the author can edit (in an editing view) using one set of stylistic preferences and publish using different styles. Authors with low vision may need large text when editing but want to publish with a smaller default text size. The style preferences of the editing view must not affect the markup of the published document.

Authoring tools must also ensure that the author can navigate a document efficiently while editing, regardless of disability. Authors who use screen readers, refreshable Braille displays, or screen magnifiers can make limited use (if at all) of graphical artifacts that communicate the structure of the document and act as signposts when traversing it. Authors who cannot use a mouse (e.g., people with physical disabilities or who are blind) must use the slow and tiring process of moving one step at a time through the document to access the desired content, unless more efficient navigation methods are available. Authoring tools should therefore provide an editing view that conveys a sense of the overall structure and allows structured navigation.

Note: Documentation, help files, and installation are part of the software and need to be available in an accessible form.

1.1 Ensure that the authoring interface follows all operating environment conventions that benefit accessibility (Applies at three priority levels: [Priority 1] for standards and conventions that are essential to accessibility; [Priority 2] for those that are important to accessibility; [Priority 3] for those that are beneficial to accessibility).

Rationale:

Techniques: Implementation Techniques for Checkpoint 1.1, Evaluation Techniques for Checkpoint 1.1

Success Criteria:

This checkpoint requires all aspects of the authoring interface to be accessible to the author. This wide scope means that the checkpoint applies to the implementation of all the other checkpoints in this guidelines document. The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications. In many cases several sets of standards will be applicable.
[@@issue 7 there is no minimum requirement here]

 

1.2 Ensure that the authoring interface enables accessible editing of all element and object properties. [Priority 1]

Note This checkpoint is a special case of checkpoint 1.1 that is especially important to authoring tools.

Techniques: Implementation Techniques for Checkpoint 1.2, Evaluation Techniques for Checkpoint 1.2

Success Criteria: provide at least one accessible way to edit every element and object property supported by the tool.

 

1.3 Ensure that the authoring interface enables the author to edit the structure of the document [Priority 2]

Note This checkpoint is a special case of checkpoint 1.1 that is especially important to authoring tools.

Techniques: Implementation Techniques for Checkpoint 1.3, Evaluation Techniques for Checkpoint 1.3

Success Criteria: the checkpoint requires that the author be able to copy, cut or paste an element and its content at any level of the document tree hierarchy.

 

1.4 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]

Note: This checkpoint applies primarily to WYSIWYG markup editing tools and requires that the author be able to view the content, as it is being authored, in a way that differs from the presumed default appearance of the rendered content.

Techniques: Implementation Techniques for Checkpoint 1.4, Evaluation Techniques for Checkpoint 1.4

Success Criteria: there must be some mechanism for changing the document display independently of the document markup.

There are a number of ways that this can be achieved, including supporting operating environment display preferences and allowing the author to specify an editing style sheet that is different from those included with the published document. In addition, there must be some means by which textual alternatives can be displayed to the author in place of non-text elements. [@@Issue 8 - need to clean this paragraph up - some is techniques, plus wording and some is useful for the checkpoint]

1.5 Ensure that the authoring interface enables accessible navigation of editing views via the document structure. [Priority 2]

Rationale: simplify navigation for the author.

Techniques: Implementation Techniques for Checkpoint 1.5, Evaluation Techniques for Checkpoint 1.5

Success Criteria: the author should be able to move from element to element. [@@Issue 9: is this actually what we need?]

 

1.6 Ensure the authoring interface allows the author to search within the editing views. [Priority 2]

Rationale: Search functions facilitate author navigation of content as it is being authored. Most markup editing tools will already provide a search function, other authoring tools (i.e. multimedia editors, etc.) may not.

Techniques: Implementation Techniques for Checkpoint 1.6, Evaluation Techniques for Checkpoint 1.6

Success Criteria:

The purpose of this checkpoint is to encourage authoring tool developers to include search functions into their tools in order to facilitate navigation of the content as it is authored. This search capability may be as simple as a string matching "find" function in a basic text editor or as complex as search functions that take advantage of the structure (elements, attributes, etc.) inherent in marked-up content.

As this is a checkpoint within Guideline 7 (Ensure that the Authoring Tool is Accessible to Authors with Disabilities) there is one other implicit requirement: that is that the search function must able to move the editing focus immediately to the occurrences that it finds (one at a time s requested by the author). A tool that merely highlights all the found occurrences simultaneously without allowing the author to quickly move the editing focus to the occurrences is not helpful as a document navigation function.

the tool should allow basic text search with a choice of skipping or including markup

 

GUIDELINE 2: Ensure that the tool is designed to produce accessible content

The most basic determinant of the accessibility of Web content is the degree to which the authoring tool that produced it was designed with attention to markup validity and accessibility. Tools that generate and preserve high quality markup are well prepared to meet the other guidelines.

Generating standard markup:

Conformance with standards promotes interoperability and accessibility by making it easier to create specialized user agents that address the needs of users with disabilities. In particular, many assistive technologies used with browsers and multimedia players are only able to provide access to Web documents that use valid markup. Therefore, valid markup is an essential aspect of authoring tool accessibility.

Where applicable use W3C Recommendations, which have been reviewed to ensure accessibility and interoperability. If there are no applicable W3C Recommendations, use a published standard that enables accessibility.

2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2]

Rationale: Many of the W3C language recommendations have been designed with accessibility as a goal. In addition, the W3C has published Notes for some of its most popular language recommendations, describing best use practices. As a result, building accessibility-aware authoring tools for W3C languages should be easier than for other language formats that lack these supports.

Techniques: Implementation Techniques for Checkpoint 2.1, Evaluation Techniques for Checkpoint 2.1

Success Criteria:

1. Using a W3C language Recommendation may involve reading and/or writing Web content in that language format.
2. The tool may use non-W3C formats, in addition to the W3C Recommendations.
3. A W3C Recommendation is considered available to a specific version of an authoring tool, if the Recommendation has reached the Candidate Recommendation phase at least two (2) years before the version of the tool in question is released for use.
4. Whether a W3C Recommendation is appropriate depends on a comparison of the features of the tool with the requirements of the task. Critical appropriateness criteria will depend on the task, but may include support for media, scripting, or styling. When comparing the appropriateness of W3C recommendations with non-W3C formats for a particular task, accessibility must be included as a comparison criteria.
5. Inform the author in marketing, packaging and documentary material of the name and version of any W3C Recommendations used. This notice must specify whether the conformance with the Recommendation is full or partial.

 

2.2 Ensure that markup which the tool automatically generates is valid for the language the tool is generating. [Priority 1]

Rationale: Following language specifications is the most basic requirement for accessible content production. When content is valid, it is easier to check and correct accessibility errors and user agents are better able to render the content properly and personalize the content to the needs of individual users.

Techniques: Implementation Techniques for Checkpoint 2.2, Evaluation Techniques for Checkpoint 2.2

Success Criteria:

1. All markup strings written by the tool are valid as defined by the relevant W3C Language Recommendation or othe format specification, unless the markup has been authored "by hand".
2. Markup strings that the tool writes as a result of the author selecting elements or attributes by name from lists, toolbar buttons, etc. are valid as defined by the relevant W3C Language Recommendation or othe format specification.

 

Supporting accessible authoring practices:

If the tool automatically generates markup, many authors will be unaware of the accessibility status of the final content unless they expend extra effort to review it and make appropriate corrections by hand. Since many authors are unfamiliar with accessibility, authoring tools are responsible for automatically generating accessible markup, and where appropriate, for guiding the author in producing accessible content.

Many applications feature the ability to convert documents from other formats (e.g., Rich Text Format) into a markup format specifically intended for the Web such as HTML. Markup changes may also be made to facilitate efficient editing and manipulation. It is essential that these processes do not introduce inaccessible markup or remove accessibility content, particularly when a tool hides the markup changes from the author's view.

2.3 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1]

Rationale: The most basic support for accessbility is ensuring that is at least possible for the author to produce accessible content. Without this posssibility, further efforts are futile. The simplest way to assure this possibility exists is to allow authoring "by hand", so that well-informed authors can work around any accessibility shortcomings in the automatic generation of markup. However, tools that only generate markup automatically must ensure the accessibility of all generated markup in order to meet this requirement.

Techniques: Implementation Techniques for Checkpoint 2.3, Evaluation Techniques for Checkpoint 2.3

Success Criteria:

1. A method for authoring "by hand" is provided (e.g. code editing view).

If authoring "by hand" is not provided then:

1. Tools that provide the author with choice as to how content will be marked up, must ensure accessible alternatives to every inaccessible choice.
2. Tools that generate content automatically always generate accessible markup. (In other words, the tool meets Checkpoint 2.5 to Relative Priority Level 3).

 

2.4 Ensure that the tool preserves all accessibility information during transformations, and conversions. [Priority 1]

Rationale: Once the author has made the effort to add accessible content, either manually or with the aid of the authoring tool, it would be highly inconvenient for the authoring tool not to take care with that content when converting (i.e. taking content encoded in one markup language and re-encoding it in another) or transforming it (i.e. modifying the encoding of content without changing the markup language). Note: Differences in grammatical richness must be taken into account, between markup languages in the case of conversions, and between markup entities in the case of conversions.

Techniques: Implementation Techniques for Checkpoint 2.4, Evaluation Techniques for Checkpoint 2.4

Success Criteria:

1. When transformations or conversions move content from a grammatically-rich to grammatically-poor languages or markups entities, the structure of the content may need to be flattened to the point where it is insufficient to allow the reversal of the transformation. To ameliorate this problem, utilize as much of structural richness of the target language or markup entity as possible.
2. When reversal of the transformation is not possible, the author is notified author.
3. Equivalent alternatives (e.g. labels, descriptions, etc.) are preserved during every transformation or conversion, such that the information is still available and useful for the purpose of providing equivalent information for the non-text element.
4. Structural information (e.g. heading, etc.) is preserved during every transformation or conversion, such that that the information is still available and useful for navigation.
5. Separation of content from presentation is preserved during every transformation or conversion, such that content is still separate from presentation to the degree possible in the new format.

 

2.5 Ensure that when the tool automatically generates content it conforms to the WCAG. [Relative Priority]

Rationale: Authoring tools that automatically generate content that does not conform to WCAG are an obvious source of accessibility problems. If the tool includes checking and correction tools, problems result in inconvenieence as the author must correct errors which were completely under the control of the tool. If the tool does not include checking and correction tools, the result is almost certainly WCAG non-conformant documents.

Techniques: Implementation Techniques for Checkpoint 2.5, Evaluation Techniques for Checkpoint 2.5

Success Criteria:

1. All markup strings written by the tool are accessible as defined by WCAG (see Note on Relative Priority), unless the markup has been authored "by hand".
2. Markup strings that the tool generates from author selections of elements and attributes by name (e.g. from lists. etc.) are accessible as defined by WCAG (see Note on Relative Priority).
3. This applies to the choice of markup type, file type, and markup practices.
4. The tool may provide the author with the option of disabling or altering the accessible defaults.

 

2.6 Ensure that all pre-authored content for the tool conforms to WCAG. [Relative Priority]

Rationale: Pre-authored content is included with authoring tools for the convenience of the author. Including WCAG conformant pre-authored content (e.g. accessible markup and content for templates, alt text, long descriptions for images, captions, auditory descriptions and collated text transcriptions for multimedia objects, and accessible design and functional alternatives for applets and scripts, etc.) increases that convenience by (1) ensuring that authors can use any of the content without concern for the accessibility implications and (2) prevents each individual author from having to compose their own version of alternative content when this task could have been done just once by the distributor.

Techniques: Implementation Techniques for Checkpoint 2.6, Evaluation Techniques for Checkpoint 2.6

Success Criteria:

1. All Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc) included with distribution of the tool or provided preferentially to the users of the tool, must conform to WCAG (see Note on Relative Priority). Preferential offerings include those in the distribution file or media as well as those offerered by the developer or its partners that may be accessed in a way that authors not using the tool would not (e.g. free clip art for registered owners, etc.).
2. Objects that require alternative descriptions (see WCAG) have this information stored internally (e.g. as text tracks) or externally (e.g. as files, database entries in a management system - see Checkpoint 3.4, etc.).

 

2.7 Allow the author to preserve markup not recognized by the tool. [Priority 2]

Rationale: Markup that is not recognized by an authoring tool may have been added to enhance accessibility.

Techniques: Implementation Techniques for Checkpoint 2.7, Evaluation Techniques for Checkpoint 2.7

Success Criteria:

1. Preserve all well-formed markup.
2. Or query the author for their consent before removing or changing unrecognized markup.
3. It is acceptable for a tool to refuse to open a document that contains markup that it cannot process, but that the author chooses to retain.

 

GUIDELINE 3: Support the author in the production of accessible content

While ensuring the accessibility of automated output provides a solid foundation, the author will likely act in ways that confound this. Therefore, it is especially important that the authoring tool support the author by guiding them in matters that involve an element of human judgment or creativity, providing automated or semi-automated checking and correction facilities and by providing high quality accessibility documentation.

Guiding the author to produce accessible content:

Well-structured information and equivalent alternative information are cornerstones of accessible design, allowing information to be presented in a way most appropriate for the needs of the user without constraining the creativity of the author. However, producing equivalent information, such as text alternatives for images and auditory descriptions of video, can be one of the most challenging aspects of Web design, and authoring tool developers should attempt to facilitate and automate the mechanics of this process. For example, prompting authors to include equivalent alternative information such as text equivalents, captions, and auditory descriptions at appropriate times can greatly ease the burden for authors. Where such information can be mechanically determined and offered as a choice for the author (e.g., the function of icons in an automatically-generated navigation bar, or expansion of acronyms from a dictionary), the tool can assist the author. At the same time, the tool can reinforce the need for such information and the author's role in ensuring that it is used appropriately in each instance.

3.1 Assist the author to create structured content. [Relative Priority]

Rationale: While structuring content and separating content from presentation is important from an accessibility standpoint, it is often counter-intuitive to accustumed to implicitly encoding the context of information into its visual "look". Therefore, supporting the author in this aspect of markup production is crucial. Note: Some checkpoints in Web Content Accessibility Guidelines 2.0 [ WCAG20] do not apply.

Techniques: Implementation Techniques for Checkpoint 3.2, Evaluation Techniques for Checkpoint 3.2

Success Criteria:

1. the tool has provided the author with an explicit method of specifying the structure, authoring content independent of presentation and authoring presentation style sheets.
2. The content created by the average author will have structural markup to allow navigation of the document using the structure. Text elements can be flexibly rendered using various style sheets or display preferences without author intervention. Non-text elements can be flexibly laid out.

 

3.2 Assist the author to separate information from its presentation. [Relative Priority]

Rationale:

Techniques:

Success Criteria:

 

3.3 Assist the author to ensure device independent control. [Relative Priority]

Rationale:

Techniques:

Success Criteria:

 

Accessible Equivalents

3.4 Prompt the author to provide equivalent alternative information (e.g., captions, auditory descriptions, and collated text transcripts for video). [Relative Priority - See Implementation Techniques for applicable WCAG checkpoints.]

Rationale: This checkpoint is intended to result in typical tool users providing equivalent alternatives for all non-text elements (including alternate text, captions, auditory descriptions, collated text transcripts for video, etc.). Different tools will accomplish this goal in ways appropriate to their product and their users.

Techniques: Implementation Techniques for Checkpoint 3.1, Evaluation Techniques for Checkpoint 3.1

Success Criteria:

1. The authoring tool reminds the author to provide equivalent alternatives for each instance of non-text content.
2. The reminder is made available to the author at least once prior to completion of authoring,
3. Non-text content with pre-existing equivalent alternatives are exempt from this requirement, if the function of the content is known with certainty and is matched by the stored alternative (see Checkpoint 3.5).

 

3.5 Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

Rationale: Improperly generated alternatives can interfere with accessibility checking.

Techniques: Implementation Techniques for Checkpoint 3.3, Evaluation Techniques for Checkpoint 3.3

Success Criteria:

1. When a new object is inserted the tool has prompted the author to enter an appropriate equivalent alternative without providing a generated default entry.
2. Only an alternative that has been explicitly associated with an object is offered as a default entry for the author to approve.
3. In content authored by the average author there are no improperly generated alternatives.

 

3.6 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3]

Rationale: Simplifying the initial production and later reuse of alternative equivalents will encourage authors to use them more frequently. In addition, such a alternative equivalent management system will facilitate meeting the requirements of Checkpoint 3.3.

Techniques: Implementation Techniques for Checkpoint 3.4, Evaluation Techniques for Checkpoint 3.4

Success Criteria:

1. The author is able to reuse or re-purpose previously authored alternative equivalents to provide meaningful alternative equivalents.

 

Checking and correcting inaccessible content:

Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can configure the tool's accessibility features to support their regular work patterns are more likely to accept accessible authoring practices (see guideline 5). For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may prefer to perform a check at the end of an editing session. This is analogous to programming environments that allow users to decide whether to check for correct code during editing or at compilation.

Note: Validation of markup is an essential aspect of checking the accessibility of content.

3.7 Check for and inform the author of accessibility problems. [Relative Priority]

Rationale: provide the author with a utility that helps check documents for accessibility problems.

Techniques: Techniques for checkpoint 3.5, Evaluation Techniques for Checkpoint 3.5.

At minimum (required basic functionality): this utility must provide at least one, automated or manual, check for each WCAG 2.0 [WCAG20] checkpoint (of relevant priority). When this utility runs it must always check those questions pertaining to "In General" WCAG 2.0 checkpoints, but only those "conditional" WCAG 2.0 checkpoints that have their conditions fulfilled by the document.

1. The average author is aware of accessibility problems within the document.

 

3.8 Assist authors in correcting accessibility problems. [Relative Priority]

Rationale: once accessibility problems have been found, help the author to correct them properly.

Techniques: Techniques for checkpoint 3.6, Evaluation Techniques for Checkpoint 3.6

Success Criteria:, provide context-sensitive help with the accessibility checking required by checkpoint 3.5.

1. The average author is able to successfully correct identified accessibility problems.

 

3.9 Provide the author with a summary of the document's accessibility status. [Priority 3]

Rationale: encourage authoring tools to notify authors of accessibility problems in a coherent way.

Techniques: Techniques for checkpoint 3.7, Evaluation Techniques for Checkpoint 3.7.

Success Criteria:

1. The average author, following review of help and documentation will be aware of and able to use features of the tool that promote accessibility.

 

Promoting accessibility in help and documentation:

Web authors may not be familiar with accessibility issues that arise when creating Web content. Therefore, help and documentation must include explanations of accessibility problems, and should demonstrate solutions with examples.

3.10 Document all features of the tool that promote the production of accessible content. [Priority 1]

Rationale: As with any feature, documentation of all the accessibility related feature of the tool (dialog boxes, utility, code views, etc.) will facilitate authors finding and using them, effectively.

Techniques: Techniques for checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8.

Success Criteria:

1. All features of the tool that help create accessible content are documented.

 

3.11 Document the process of using the tool to produce accessible content. [Relative Priority]

Rationale: Authors will be more likely to effectively use the accessibility features of the tool if a they have a workflow strategy for integrating the new accessibility related tasks inot the Web content authoring that thery already perform.

Techniques: Techniques for checkpoint 3.9, Evaluation Techniques for Checkpoint 3.9

Success Criteria:

1. The documentation contains sample suggested workflows which, if followed, will likely result in the various levels of WCAG conformance. This should include the name and nature of the features and when and how they should be used.
2. For tools that lack a particular accessibility-related feature, this workflow strategy will contain work-arounds that are likely to acheive the same result..

 

GUIDELINE 4: Integrate accessibility solutions into the overall "look and feel"

When a new feature is added to an existing software tool without proper integration, the result is often an obvious discontinuity. Differing color schemes, fonts, interaction styles, and even software stability can be factors affecting author acceptance of the new feature. In addition, the relative prominence of different ways to accomplish the same task can influence which one the author chooses. Therefore, it is important that creating accessible content be a natural process when using an authoring tool.

4.1 Ensure that the functionalities for checkpoints 3.1, 3.2, 3.5 and 3.6 are always clearly available to the user [Priority 1]

Rationale: The user must be easily able to turn on accessibility support functionality.

Techniques: Implementation Techniques for Checkpoint 4.1, Evaluation Techniques for Checkpoint 4.1

See Also: ATAG Checkpoints 3.1, 3.2, 3.5 and 3.6.

Success Criteria:

1. If accessibility-related functionalities (see Checkpoint 3.1, Checkpoint 3.2, Checkpoint 3.5, and Checkpoint 3.6) are not already active by default, the mechanism for activating them must be available to the author: (1) at all times during authoring and (2) at most, one level down in the user interface (e.g. in the first level of a drop-down menu).
2. The configuration mechanism (i.e. preferences, options, etc.) for these accessibility-related functionalities must be designed so that (1) authors searching for the configuration mechanism will find it easily and (2) authors performing general configuration tasks will readily notice the configuration mechanism.
3. When these accessibility-related functionalities are combined with other functionalities in an authoring mechanism (i.e. one accessibility-related field in a general purpose dialog box), the design must allow (1) authors searching for the functionality to find it easily and (2) authors performing the other general purpose tasks to readily notice the functionality.

 

4.2 Ensure that accessible authoring practices supporting the minimum requirements for all WCAG checkpoints are among the most obvious and easily initiated by the author. [Priority 2]

Rationale: For accessibility-related functionality to be accepted by authors, it must be integrated as seamlessly as possible.

Techniques: Implementation Techniques for Checkpoint 4.2, Evaluation Techniques for Checkpoint 4.2

Success Criteria:

1. When an authoring action does not necessarily demand a particular markup implementation (ex. changing the color of text), the markup implementation(s) that meet the minimum requirements of WCAG must have at least the same user interface visibility and at least the same ease of function activation (in terms of mouse clicks and keystrokes) as markup implementations that do no meet those requirements.
2. Whenever a tool provides a means for markup (that has not be authored "by hand") to be added into a document by one mouse click or keystroke, that markup must meet the minimum requirements of WCAG.

 

4.3 Ensure that all functionality (prompts, checkers, information icons, etc.) related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2]

Rationale: User interfaces can increase the probability that authors will use accessible authoring practices, even when less accessible alternatives are provided by the tool for reasons of completeness.

Techniques: Implementation Techniques for Checkpoint 4.3, Evaluation Techniques for Checkpoint 4.3

Success Criteria:

1. The accessibility-related functionalities do not contrast with analagous functionality in the normal operation of the tool. For example, an accessibility checker is analagous to spell checker, while a prompt for a accessibility-related label is analagous to a prompt for a document title. The following factors must be considered: (1) Visual Design: Design metaphors, artistic sophistication, sizes, fonts, colours, (2) Operation: The degree of automation, the approximate number of mouse clicks or keystrokes, (3) Complexity: The amount of author instruction required, and (4) Flexibility: The configurability of the functionality and its features.
2. The separation of accessibility-related functionalities from the normal authoring process, should be minimized. ????

 

4.4 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority ?] [@@ No longer relative - suggested P2]

Rationale: This checkpoint promotes the production of accessible content by implicitly demonstrating to the author that all content, regardless of purpose, should comply with the WCAG guidelines.

Techniques: Implementation Techniques for Checkpoint 4.4, Evaluation Techniques for Checkpoint 4.4

Success Criteria:

1. All markup code examples must meet the all requirements of WCAG, regardless of the purpose of the example.
2. Only the WCAG requirements appropriate to code segments of the size in question are required. For example, no navigation mechanism is required for an example comprised of only one element,
3. All examples of the authoring tool interface, including screenshots of dialog boxes, code views, etc., included within the documentation must not violate any of the requirements of WCAG, regardless of the purpose of the example. For example, a screenshot of an image properties dialog that has been cropped so as to include a field for a short descriptive text label must ensure a text label is added to that field.

 

3. Glossary of Terms and Definitions

Accessibility (Also: Accessible)

Within these guidelines,"accessible Web content" and "accessible authoring tool" mean that the content and tool can be used by people regardless of disability. To understand the accessibility issues relevant to authoring tool design, consider that many authors may be creating content in contexts very different from your own:

• They may not be able to see, hear, move, or may not be able to process some types of information easily or at all;
• They may have difficulty reading or comprehending text;
• They may not have or be able to use a keyboard or mouse;
• They may have a text-only display, or a small screen.

Accessible design will benefit people in these different authoring scenarios and also many people who do not have a physical disability but who have similar needs. For example, someone may be working in a noisy environment and thus require an alternative representation of audio information. Similarly, someone may be working in an eyes-busy environment and thus require an audio equivalent to information they cannot view. Users of small mobile devices (with small screens, no keyboard, and no mouse) have similar functional needs as some users with disabilities.

Accessibility Information

"Accessibility information" is content, including information and markup, that is used to improve the accessibility of a document. Accessibility information includes, but is not limited to, equivalent alternative information.

Accessibility Problem (Also: Inaccessible Markup)

Inaccessible Web content or authoring tools cannot be used by some people with disabilities. The Web Content Accessibility Guidelines 2.0 [WCAG20] describes how to create accessible Web content.

Accessible Authoring Practice

"Accessible authoring practices" improve the accessibility of Web content. Both authors and tools engage in accessible authoring practices. For example, authors write clearly, structure their content, and provide navigation aids. Tools automatically generate valid markup and assist authors in providing and managing appropriate equivalent alternatives.

Alert

An "alert" draws the author's attention to an event or situation. It may require a response from the author.

Alternative Information (Also: Equivalent Alternative)

Content is "equivalent" to other content when both fulfill essentially the same function or purpose upon presentation to the user. Equivalent alternatives play an important role in accessible authoring practices since certain types of content may not be accessible to all users (e.g., video, images, audio, etc.). Authors are encouraged to provide text equivalents for non-text content since text may be rendered as synthesized speech for individuals who have visual or learning disabilities, as Braille for individuals who are blind, or as graphical text for individuals who are deaf or do not have a disability. For more information about equivalent alternatives, please refer to the Web Content Accessibility Guidelines WCAG 2.0 [WCAG20].

Attribute

This document uses the term "attribute" as used in SGML and XML [XML]: Element types may be defined as having any number of attributes. Some attributes are integral to the accessibility of content (e.g., the "alt", "title", and "longdesc" attributes in HTML).

Auditory Description

An "auditory description" provides information about actions, body language, graphics, and scene changes in a video. Auditory descriptions are commonly used by people who are blind or have low vision, although they may also be used as a low-bandwidth equivalent on the Web. An auditory description is either a pre-recorded human voice or a synthesized voice (recorded or automatically generated in real time). The auditory description must be synchronized with the auditory track of a video presentation, usually during natural pauses in the auditory track.

Authored "by hand"

When the author specifies the precise text string, as by typing into a text editor.

Authoring Tool

An "authoring tool" is any software that is used to produce content for publishing on the Web. Authoring tools include:

• Editing tools specifically designed to produce Web content (e.g., WYSIWYG HTML and XML editors);
• Tools that offer the option of saving material in a Web format (e.g., word processors or desktop publishing packages);
• Tools that transform documents into Web formats (e.g., filters to transform desktop publishing formats to HTML);
• Tools that produce multimedia, especially where it is intended for use on the Web (e.g., video production and editing suites, SMIL authoring packages);
• Tools for site management or site publication, including tools that automatically generate Web sites dynamically from a database, on-the-fly conversion and Web site publishing tools;
• Tools for management of layout (e.g., CSS formatting tools).

Captions

"Captions" are essential text equivalents for movie audio. Captions consist of a text transcript of the auditory track of the movie (or other video presentation) that is synchronized with the video and auditory tracks. Captions are generally rendered graphically and benefit people who can see but are deaf, hard-of-hearing, or cannot hear the audio.

Conversion Tool

A "conversion tool" is any application or application feature (e.g.,"Save as HTML") that transforms convert in one format to another format (such as a markup language).

Check for

As used in checkpoint 4.1,"check for" can refer to three types of checking:

1. In some instances, an authoring tool will be able to check for accessibility problems automatically. For example, checking for validity (checkpoint 2.2) or testing whether an image is the only content of a link.
2. In some cases, the tool will be able to "suspect" or "guess" that there is a problem, but will need confirmation from the author. For example, in making sure that a sensible reading order is preserved a tool can present a linearized version of a page to the author.
3. In some cases, a tool must rely mostly on the author, and can only ask the author to check. For example, the tool may prompt the author to verify that equivalent alternatives for multimedia are appropriate. This is the minimal standard to be satisfied. Subtle, rather than extensive, prompting is more likely to be effective in encouraging the author to verify accessibility where it cannot be done automatically.

Document

A "document" is a series of elements that are defined by a markup language (e.g., HTML 4 or an XML application).

Editing View

An "editing view" is a view provided by the authoring tool that allows editing.

Element

An "element" is any identifiable object within a document, for example, a character, word, image, paragraph or spreadsheet cell. In [HTML4] and [ XML], an element refers to a pair of tags and their content, or an "empty" tag - one that requires no closing tag or content.

Inform

To "inform" is to make the author aware of an event or situation through alert, prompt, sound, flash, or other means.

Markup Language

Authors encode information using a "markup language" such as HTML [HTML4], SVG [ SVG], or MathML [MATHML].

Presentation Markup

"Presentation markup" is markup language that encodes information about the desired presentation or layout of the content. For example, Cascading Style Sheets [CSS1], [CSS2] can be used to control fonts, colors, aural rendering, and graphical positioning. Presentation markup should not be used in place of structural markup to convey structure. For example, authors should mark up lists in HTML with proper list markup and style them with CSS (e.g., to control spacing, bullets, numbering, etc.). Authors should not use other CSS or HTML incorrectly to lay out content graphically so that it resembles a list.

Prompt

In this document prompt does not refer to the narrow software sense of a "prompt," rather it is used as a verb meaning to urge, suggest and encourage. The form and timing that this prompting takes can be user configurable. "Prompting" does not depend upon the author to seek out the support but is initiated by the tool. "Prompting" is more than checking, correcting, and providing help and documentation as encompassed in guidelines 4, 5, 6. The goal of prompting the author is to encourage, urge and support the author in creating meaningful equivalent text without causing frustration that may cause the author to avoid access options. Prompting should be implemented in such a way that it causes a positive disposition and awareness on the part of the author toward accessible authoring practices.

Property

A "property" is a piece of information about an element, for example structural information (e.g., it is item number 7 in a list, or plain text) or presentation information (e.g., that it is marked as bold, its font size is 14). In XML and HTML, properties of an element include the type of the element (e.g., IMG or DL), the values of its attributes, and information associated by means of a style sheet. In a database, properties of a particular element may include values of the entry, and acceptable data types for that entry.

Structural Markup

"Structural markup" is markup language that encodes information about the structural role of elements of the content. For example, headings, sections, members of a list, and components of a complex diagram can be identified using structural markup. Structural markup should not be used incorrectly to control presentation or layout. For example, authors should not use the BLOCKQUOTE element in HTML [HTML4]to achieve an indentation visual layout effect. Structural markup should be used correctly to communicate the roles of the elements of the content and presentation markup should be used separately to control the presentation and layout.

Transcript

A "transcript" is a text representation of sounds in an audio clip or an auditory track of a multimedia presentation. A "collated text transcript" for a video combines (collates) caption text with text descriptions of video information (descriptions of the actions, body language, graphics, and scene changes of the visual track). Collated text transcripts are essential for individuals who are deaf-blind and rely on Braille for access to movies and other content.

Transformation

A "transformation" is a process that changes a document or object into another, equivalent, object according to a discrete set of rules. This includes conversion tools, software that allows the author to change the DTD defined for the original document to another DTD, and the ability to change the markup of lists and convert them into tables.

User Agent

A "user agent" is software that retrieves and renders Web content. User agents include browsers, plug-ins for a particular media type, and some assistive technologies.

View

Authoring tools may render the same content in a variety of ways; each rendering is called a "view". Some authoring tools will have several different types of view, and some allow views of several documents at once. For instance, one view may show raw markup, a second may show a structured tree, a third may show markup with rendered objects while a final view shows an example of how the document may appear if it were to be rendered by a particular browser. A typical way to distinguish views in a graphic environment is to place each in a separate window.