Authoring Tool Accessibility Guidelines 2.0

1.1 Definition of Authoring Tool

Any software or service that authors may use to create or modify Web content for publication. This includes software that enables authors to perform any of the following functions:

1. Text Editing: Authors manipulate plain text data (e.g. markup text, program code, etc.). [Example 1]
2. Symbol-Level Editing: Authors manipulate symbols (not WYSIWYG renderings) that represent low-level functional groups in the underlying plain text data (e.g. symbols in place of markup elements, programming code operations, multi-element placeholder, etc.) .[Example 2]
3. WYSIWYG Editing: Authors manipulate browser-like renderings of the underlying plain text data (e.g. rendered text, images, etc. in place of markup elements). [Example 3]
4. Graphics Editing: Authors manipulate renderings of object-oriented graphics (e.g. rendered lines, etc. in place of markup elements in a drawing program, animation tool stage, etc.). [Example 4]
5. Content Management: Authors exercise control of changes to Web content across whole documents or groups of documents, rather than at the level of individual instances of content (e.g. site building wizards, site management tools, courseware, content aggregators, etc.). [Example 5]
6. Constrained Editing: Authors make highly constrained inputs that are structured and styled according to static templates (e.g. guest books, message boards, etc.). [Example 6]
7. Timeline Editing: Authors manipulate time-dependent Web content (e.g. animation, music, etc.) using a user interface that represents a series of frames. [Example 7]
8. Format Conversion: Authors are assisted in causing Web content encoded in one format to become encoded in another (e.g. saving Web content created in one format in a different format, importing Web content from a different format, etc.) [Example 8]

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 sufficiently specific to be verifiable, 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.

1.4 Checkpoint priorities

Each checkpoint in the specification has been assigned one of the following priority levels to indicate the importance of the checkpoint in satisfying the guidelines:

GUIDELINE 1: Ensure that the tool itself is accessible

An 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. Authors who use screen readers, refreshable Braille displays, or screen magnifiers can make limited use (if any) of graphical artifacts that communicate the structure of the document and act as signposts when traversing it. Authors who cannot use a mouse (especially 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 applicable software accessibility guidelines. ([Priority 1] for required elements of the software accessibility guidelines; [Priority 3] for recommended elements of the software accessibility guidelines.)

Rationale: If the authoring tool interface does not follow these conventions, the author who depends upon the techniques associated with the conventions is not likely to be able to use the tool.

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

Success Criteria:

1. The authoring interface must pass the Software Accessibility Guidelines testing criteria. (Priority 1 for Required criteria; Priority 3 for Recommended criteria)

Specific considerations when designing an accessible authoring interface

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

Rationale: Element or object properties displayed and edited through graphic means are not accessible to authors using screen readers, Braille displays or screen enhancers. The explicit property value should be accessible to those technologies which read text and support authors editing text.

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

Success Criteria:

1. At least one editing method must pass the Software Accessibility Guidelines testing criteria for each element and object property editable by the tool. (Priority 1 for Required criteria; Priority 3 for Recommended criteria)

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

Rationale: Authors may require a set of display preferences to view and control the document that is different from the desired default
display style for the published document (e.g. a particular text-background combination that differs from the published version).

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

Success Criteria:

1. All editing views must display text equivalents for any the non-text content
2. The editing views must either respect the following operating system display settings or provide equivalent functions for displaying text content without affecting the display settings in the content markup:
3. All editing views must either respect operating system display settings (for color, contrast, size, and font) or, from within the tool, provide a means of changing color, contrast, size and font, without affecting the content markup.

1.4 Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 2]

Rationale:
Efficient authoring requires that the author be able to move quickly to arbitrary locations in the content and, once there, make modifications beyond character-by-character edits. This is usually best accomplished by making use of any explicit structure that may have been encoded with hierarchy-based markup. When explicit structure is unavailable, the implicit structure in the visual look and layout of content may sometimes be used.

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

Success Criteria:

1. In any element hierarchy, the author must be able to move editing focus from any structural element to any element (if any) immediately above, immediately below or in the same level in the hierarchy.
2. In any element hierarchy, the author must be able to select, copy, cut and paste any whole element with its their content.

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

Rationale: Search functions, such as simple string matching or more complex mechanisms that take advantage of the structure (elements, attributes, etc.) inherent in marked-up content, facilitate author navigation of content as it is being authored.@@ revisit this in light of new success criteria. @@

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

Success Criteria:

1. The authoring tool must have a search function for all every editing views.
2. The author must be able to search for text within all text equivalents of any rendered non-text content.
3. The author must be able to specify whether they wish to search content, markup, or both.

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 gives priority 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 the accessibility compliance of an authoring tool.

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

2.1 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' devices.

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

Success Criteria:

1. All markup strings written by the tool must be valid, as defined by the relevant W3C Recommendation or other format specification. This does not apply where the markup itself has been authored "by hand".
2. All markup strings written automatically by the tool (i.e. not authored "by hand") must conform to the applicable markup language specification.

2.2 Use the latest versions of W3C format Recommendations when they are available and appropriate for a task. [Priority 2] @@ed. group must decide whether to keep this checkpoint in its current form@@

Rationale: The W3C has implemented an accessibility review process for language recommendations that has resulted in addition of supports for accessibility within many of these languages as well as published Notes describing best use practices for some of the most popular languages. Because this process is ongoing, more recent versions of W3C language recommendations are likely to include better supports for accessibility than older ones.

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

Success Criteria:

1. Provide an accessible reading of web content in available, relevant W3C recommended language format and provide accessible means for editing and writing 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 the features of the tool. Critical relevance criteria will depend on the task, but may include support for media, scripting, or styling. When comparing the appropriateness of W3C recommendations with other, non-W3C formats for a particular task, accessibility must be included as a comparison criteria.
5. Inform the author in marketing, packaging and other 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.

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 other content intended to increase accessibility, 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: If it is at least possible for the author to produce accessible content, then well-informed authors may be able to work around any accessibility short-comings in the rest of the authoring tool.

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).
2. Tools must always meet at least one of the following:
   • generate accessible content automatically
   • provide a method for authoring "by hand"
   • provide the author with accessible options for every authoring task

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] @@ed. should this be Relative Priority???@@

Rationale: Authors will be discouraged from adding accessibility information if it is discarded during conversions (i.e. taking content encoded in one markup language and re-encoding it in another) or transformations (i.e. modifying the encoding of content without changing the markup language).

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

Success Criteria:

1. During all transformations and conversions, any accessibility information must be preserved, unless prevented by limitations of the target format.
2. When accessibility information cannot be preserved during a conversion or transformation, the author must notified beforehand.
3. When transformations or conversions move content from grammatically-rich to grammatically-poor languages or markups entities, the structure of the content may be flattened to the point where it is insufficient to allow the reversal of the transformation. The tool must utilize as much structural richness of the target language or markup entity as is possible.
4. When reversal of the transformation is not possible, the author is notified prior to the conversion or transformation.
5. Equivalent alternatives (e.g. labels, descriptions, etc.) are preserved during every transformation or conversion and is still available and useful for the purpose of providing equivalent information for the non-text element.
6. Structural information (e.g. heading, etc.) is preserved during every transformation or conversion and is still available and useful for navigation.
7. Separation of content from presentation is preserved during every transformation or conversion and 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] @@Ensure that any automatically generated content conforms to WCAG.@@

Rationale: Authoring tools that automatically generate content that does not conform to WCAG are an obvious source of accessibility problems.

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

Success Criteria:

1. All markup strings written automatically by the tool (i.e. not authored "by hand") must conform to WCAG.
2. 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".
3. 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).
4. This applies to the choice of markup type, file type, and markup practices.
5. 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 (e.g. templates, images, videos, etc.) is often included with authoring tools for the convenience of the author. Ensuring that pre-authored content is WCAG conformant increases that convenience by ensuring that authors can use any of the content without concern for the accessibility implications and relieving subsequent authors from having to compose their own version of alternative content.

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

Success Criteria:

1. Any Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc.) preferentially licensed (i.e. better terms of use for users of tool than for others) for users of the tool, must conform to WCAG.
2. Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc.) included with the distribution of the tool or provided preferentially to authors using 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 offered by the developer or its partners to which authors not using the tool would not have access, e.g., free clip art for registered owners.
3. 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. Also, newer XML-based languages, such as XHTML 1.1, allow authors to include multiple languages in a single document, via namespaces. In the future, documents may contain metadata, including accessibility information, in another namespace. Authoring tools must not strip this information when it is encountered.

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

Success Criteria:

1. When unrecognized markup (e.g. external entity, unrecognized element or attribute name) is detected, the tool must query the author for consent to modify the markup. If the author refuses, and the markup cannot be processed, the tool must refuse to open the markup for editing.
2. All well-formed markup is preserved.
3. The author is queried for their consent before any unrecognized markup is removed or changed.
4. The tool does not interfere with content in namespaces it is not able to process.

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

Most authoring tools provide the author with at least some measure of control over the produced content. This control may extend to the level of markup coding (e.g. authoring "by hand") or it may be limited to higher-level content, such as page layout and text content (e.g. WYSIWYG editing). In either case, the intervention of the author has the potential to effect the accessibility of content, either positively, if the author is purposefully following accessibility guidelines, or negatively, if the author is not. In order to manage these effects, authoring tools should support the author by guiding them to follow accessibility authoring practices as they produce that content that involves an element of human judgment or creativity, providing automated or semi-automated checking and correction facilities and by providing high quality accessibility-related documentation.

Guiding the author to produce accessible content:

Conformance with accessibility authoring practices is an authoring constraint that is little different, in principle, from the constraint to produce valid code or grammatical text. Since the role of authoring tools is to facilitate satisfaction of authoring constraints, it is natural that tools should include features to facilitate the process of creating accessible content. For example, tools may assist authors to follow specific practices by suggesting accessible authoring practices or prompting for information that cannot be generated automatically, such as equivalent alternatives (alternate text, descriptions, captions, etc.).

Many authoring tools already allow authors to create documents with little or no need for knowledge about the underlying markup. To ensure accessibility, authoring tools must be designed so that they can (where possible, automatically) identify inaccessible markup, and enable its correction when either the markup is hidden from the author or the author does not know how to correct it.

Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can choose how to configure the tool's accessibility features to support their regular work patterns are more likely to feel comfortable with their use of the tool and be receptive to interventions from the tool. (see guideline 4). 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 choice is analogous to that offered in programming environments that allow authors to decide whether to check syntax during editing or at compilation.

3.1 Prompt and assist the author to create accessible content. [Relative Priority]

Rationale: Appropriate assistance should increase the likelihood that typical authors will create WCAG-conformant content. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes and authors.

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

Success Criteria:

1. When the actions of the author risk creating accessibility problems (e.g. image inserted, author typing invalid element into a code view, author initiating a page creation wizard, etc.), the tool must intervene to introduce the appropriate accessible authoring practice. This intervention may proceed according to a user-configurable schedule.
2. The intervention must occur at least once before completion of authoring (e.g. final save, publishing, etc.).
3. The authoring tool suggests accessible authoring practices where appropriate.
4. The authoring tool prompts (Important Definition) the author for information that cannot be generated automatically (e.g. equivalent alternatives (see Checkpoint 3.4).
5. Prompting may be combined with checking and repair, but must be made available to the author at least once prior to completion of authoring.

3.2 Check for and inform the author of accessibility problems. [Relative Priority] @@ed. Check for accessibility problems@@

Rationale: Authors may not notice or be able to identify accessibility problems.

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

Success Criteria:

1. The tool must provide a check (automated check, semi-automated check or manual check) for detecting violations of each requirement of WCAG.
2. Must provide at least one check (automated, semi-automated or manual) for each requirement of WCAG [WCAG].
3. The author is made aware of accessibility problems within the document.

3.3 Assist authors in repairing accessibility problems. [Relative Priority]

Rationale: Assistance may expedite the task of correcting some authors' accessibility problems, while other authors may be unable to correct accessibility problems without this help.

Techniques: Techniques for checkpoint 3.3, Evaluation Techniques for Checkpoint 3.3

Success Criteria:

1. The tool must provide a repair (automated repair, semi-automated repair or manual repair) for correcting violations of each requirement of WCAG.
2. Context-sensitive help, semi-automated repairs or fully automated repairs are provided for each requirement of WCAG [WCAG].
3. A typical author is able to successfully correct any identified accessibility problem.

Specific considerations when providing this guidance

3.4 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 create accessibility problems and interfere with accessibility checking.

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

Success Criteria:

1. When the author inserts an unrecognized non-text object, the tool must not insert an automatically generated text equivalent (e.g. label generated from the file name).
2. When the author inserts a non-text object for which the tool has a previously authored equivalent (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.
3. When a recognized non-text object is inserted by the tool, the tool must prompt the author to enter an appropriate text equivalent, but an automatically generated default entry may be offered.
4. Only an alternative that has been explicitly associated with an object is offered as a default entry for the author to approve.
5. For new non-text objects, the tool prompts the author to enter an appropriate equivalent alternative without providing a generated default entry.
6. Only an alternative that has been explicitly associated with an object is offered as a default entry for the author to approve.

3.5 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 an alternative equivalent management system will facilitate meeting the requirements of Checkpoint 3.4.

Techniques: Implementation Techniques for Checkpoint 3.5, Evaluation Techniques for Checkpoint 3.5

Success Criteria:

1. When non-text objects have been previously inserted using the tool, the tool must suggest any previously authored textual equivalents for that non-text object.
2. The tool recognizes when non-text objects have previously-authored alternative equivalents.
3. A typical author is able to reuse these previously-authored alternative equivalents when non-text content is reused.

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

Rationale: This summary will prompt the author to: improve the accessibility status; keep track of problems; and monitor progress.

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

Success Criteria:

1. The tool must provide the author with an option to view a listing of all current accessibility problems.
2. A listing of the current accessibility problems is available.
3. From the summary, the typical author will be able to tell whether their content meets the accessibility standard in question.

Promoting accessibility in help and documentation:

Some Web authors may not be familiar with accessibility issues that arise when creating Web content, while others may be authors familiar with these issues, but may not know how the tool can help to address them. Therefore, help and other supplied documentation must include explanations of accessibility problems, and should demonstrate solutions with examples.

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

Rationale: Without documention of the features that promote accessibility (e.g. prompts for alternates, code validators, accessibility checkers, etc.) authors may not find or use them.

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

Success Criteria:

1. All features that play a role in creating accessible content must be documented in the help system.
2. All features that help create accessible content are documented in the help system.
3. A typical author, following a review of help and other supplied documentation will be aware of and able to use features of the tool that promote accessibility.
4. All markup code examples meets all requirements of WCAG, regardless of the purpose of the example.
5. Only the WCAG requirements appropriate to code segments of the content section in question are required. For example, no navigation mechanism is required for an example comprised of only one element.
6. 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.8 Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 2]

Rationale: If authors must look somewhere special for information on accessible authoring practices, they may be unlikely to make the effort. Familiarity with these practices will be promoted by their integration.

Techniques: Implementation Techniques for Checkpoint 3.8, Evaluation Techniques for Checkpoint 3.8

Success Criteria:

1. All examples of markup code and views of the user interface (dialog screenshots, etc.) must meet the requirements of WCAG, regardless of whether the examples are intended to demonstrate accessibility authoring practices.
2. All markup code examples meet all applicable WCAG requirements. (This includes examples that are not meant to demonstrate accessibility.) For example, it is not required to show a navigation mechanism for an example comprised of only one element.
3. All authoring tool interface examples, including screenshots of dialog boxes, etc., meet all applicable WCAG requirements. For example, a screenshot of an image properties dialog that includes a field for a short descriptive text label must include a value in that field.

Applicable WCAG requirements are those appropriate to the scope of the example.

3.9 Document the workflow process of using the tool to produce accessible content. [Priority 3]Note: The definition of "workflow" still needs definition.

Rationale: Authors will be more likely to use features that promote accessibility if they understand when and how to use them.

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

Success Criteria:

1. The documentation must contain suggested content creation workflow descriptions that include how and when to use the accessibility-related features of the tool.
2. For tools that lack a particular accessibility-related feature, the workflow description must include a workaround for that feature.
3. The documentation contains sample or suggested workflows which, if followed, are likely to increase the chance of higher levels of WCAG conformance. This should include the name and nature of the features and when and how they should be used.
4. For tools that lack a particular accessibility-related feature, this workflow strategy will contain workarounds that are likely to achieve the same result.
5. A typical author should be able to find and understand this workflow documentation.

GUIDELINE 4: Promote and integrate accessibility solutions

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 accessibility prompting, checking, repair functions and documentation are always clearly available to the author [Priority 1]

Rationale: If the features that support accessible authoring are difficult to find, activate or use, they are less likely to be used. Ideally, these features should be turned on by default.

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

See Also: ATAG Checkpoints 3.1, 3.2, and 3.3.

Success Criteria:

1. If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions are not already active by default, the mechanism for activating them must be available to the author at all times during authoring and, 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 functions must be designed so that typical authors searching for the configuration mechanism will be likely to find it and that typical authors performing general configuration tasks will be likely to notice the configuration mechanism.
3. When these accessibility-related functions are combined with other authoring functions (i.e. one accessibility-related field in a general purpose dialog box), the y must be designed so that typical authors searching for the function will be likely to find it and that typical authors performing other general purpose tasks will be likely to notice the function.
4. If accessibility prompting (see Checkpoint 3.1), checking (see Checkpoint 3.2), and repairing (see Checkpoint 3.3) functions 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).
5. The configuration mechanism (i.e. preferences, options, etc.) for these accessibility-related functions 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.
6. When these accessibility-related functions are combined with other authoring functions (i.e. one accessibility-related field in a general purpose dialog box), the design must allow (1) authors searching for the function to find it easily and (2) authors performing the other general purpose tasks to readily notice the function.

4.2 Ensure that the most accessible option for an authoring task is given priority. [Priority 2]

Rationale: Authors are most likely to use the first and easiest options.

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

Success Criteria:

1. When a tool provides a means for markup to be added with a single mouse click or keystroke, that markup must meet the requirements of WCAG unless the markup was authored "by hand".
2. When an authoring action has several markup implementations (e.g. changing the color of text with presentation markup or style sheets), those markup implementation(s) that meet the requirements of WCAG must be equal to or higher on all of the following scales than those markup implementations that do not meet the WCAG requirements.
• Prominence of location (in "power tools" such as floating menus, toolbars, etc.)
• Position in layout (top to bottom and left to right in menus, dialog boxes, etc. )
• Size of control (measured as screen area)
• Actions to activate (number of mouse clicks or keystrokes)
3. 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 not meet those requirements.
4. 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.
5. Accessible documentation is available in the help subsystem.

4.3 Ensure that accessibility prompting, checking, repair functions and documentation are naturally integrated into the overall look and feel of the tool. [Priority 2]

Rationale: Most authors are reluctant to use features that depart from the conventions of a tool.

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

Success Criteria:

1. The mechanisms for accessibility prompting, checking, repair and documentation must be similar to comparable mechanisms in terms the following characteristics:
• visual design (design metaphors, artistic sophistication, sizes, fonts, colors)
• operation (degree of automation, number of actions for activation)
• configurability (number and types of features)
2. 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 a 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.
3. The separation of accessibility-related functionalities from the normal authoring process, should be minimized.