Authoring Tool Accessibility Guidelines 2.0

GUIDELINE 1: Make the authoring interface accessible

The design of all aspects of the authoring tool, including the authoring interface, installation procedure, documentation, and help files, must be accessible. Accessibility requirements must be followed when designing the authoring interface (Checkpoint 1.1) with special consideration paid to design features specific to authoring interfaces (Checkpoints 1.2-1.5).

1.1 Ensure that the authoring interface follows applicable software accessibility guidelines. [Authoring Interface Checkpoints Relative to WCAG or Authoring Interface Checkpoints Relative to ISO16071]

Rationale: If the authoring tool interface does not follow these guidelines, people with disabilities may not be able to author Web content.

Techniques: Implementation Techniques for Checkpoint 1.1

Success Criteria:

1. The authoring tool must satisfy at least one of the following conditions:
   1. At least one full-featured Web-based authoring interface must always be WCAG-conformant.
   2. At least one full-featured non-Web-based authoring interface must always be ISO16071-conformant.

1.2 Ensure that the authoring interface enables accessible editing of element and object properties. [Authoring Interface Checkpoints Relative to WCAG or Authoring Interface Checkpoints Relative to ISO16071]

Rationale: If some authors can edit or view properties with an authoring tool, then all authors must be able to do the same.

Techniques: Implementation Techniques for Checkpoint 1.2

Success Criteria:

1. The authoring tool must satisfy at least one of the following conditions:
   1. In Web-based authoring interfaces, at least one editing method for each editable property must always be WCAG-conformant.
   2. In non-Web-based authoring interfaces, at least one editing method for each editable property must always be ISO16071-conformant.

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

Success Criteria:

1. All editing views must always include an option to display any available equivalent alternatives.
2. All editing views must always include an option to keep the display settings of the authoring interface from affecting the Web content being edited.
   

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

Rationale: It is often more efficient to navigate and edit via the structure in Web content.

Techniques: Implementation Techniques for Checkpoint 1.4

Success Criteria:

1. In any element hierarchy, the author must always be able, with a device independent action, to move the editing focus from any element to any of the following elements, if they exist: the element immediately above (i.e. parent), the first element immediately below (i.e. child), the element immediately preceding at the same level (i.e. previous sibling), and the element immediately following at the same level (i.e. next sibling).
2. In any element hierarchy, the author must always be able, with a device independent action, to select, copy, cut and paste any element along with any content, including subelements.

1.5 Ensure that 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 by allowing the author to move focus quickly to arbitrary points in the content. Including the capability to search within text equivalents of rendered non-text content increases the efficiency of the search function.

Techniques: Implementation Techniques for Checkpoint 1.5

Success Criteria:

1. All editing views must always include a search function that meets these conditions:
   1. provides search within any rendered Web content
   2. provides the option to search markup when the tool allows direct editing of markup (e.g. when authored "by hand").
   3. provides the option to search for text within all text equivalents of any non-text content.

GUIDELINE 2: Enable the production of accessible content

The creation of accessible content is dependent on the actions of the tool and the author. This guideline delineates the responsibilities that rest exclusively with the tool.

The first responsibility is to support formats that enable accessible content (Checkpoint 2.1). Web content produced by an authoring tool is most likely to be accessible, if the content is created in accordance with the requirements of WCAG and preserved in that state throughout the authoring process. The checkpoint requirements that support this include preserving accessible or unknown content (Checkpoint 2.2), automatically generating accessible content (Checkpoint 2.3), and including accessible pre-authored content (Checkpoint 2.4).

 

2.1 Support formats that enable the creation of Web content that conforms to WCAG. [Priority 1]

Rationale: Formats with published WCAG techniques documents facilitate the creation of accessible Web content.

Techniques: Implementation Techniques for Checkpoint 2.1

Success Criteria:

1. Any authoring tool that chooses the format of content for the author (i.e. a default format) must always choose formats for which there are published WCAG techniques documents for meeting each WCAG checkpoint.
2. Any authoring tool that allows authors to choose the format of content must support at least one format for which there is a published WCAG techniques documents for meeting each WCAG checkpoint and always give prominence to those formats.

2.2 Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]

Rationale: Unrecognized markup may include recent technologies that have been added to enhance accessibility and should be preserved 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). Accessibility information should also be preserved.

Techniques: Implementation Techniques for Checkpoint 2.2

Success Criteria:

1. All transformations and conversions supported by the authoring tool must always meet both of the following conditions:
   1. the author is notified before any unrecognized markup is permanently removed.
   2. all accessibility information is handled according to at least one of the following:
      1. be preserved in the target format such that the information can be "round-tripped" by the same tool.
      2. be preserved in some other way in the target format.
      3. be removed only after the author has been notified and the content has been preserved in its original format.

2.3 Ensure that when the tool automatically generates content it conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

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

Note: WCAG includes a markup validity requirement.

Techniques: Implementation Techniques for Checkpoint 2.3

Success Criteria:

1. All markup and content that is automatically generated (in formats for which there is a published WCAG techniques documents for meeting each WCAG checkpoint) by the authoring tool (i.e. not authored "by hand") must always conform to WCAG (determine level).

2.4 Ensure that all pre-authored content for the tool conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: Pre-authored content (e.g. templates, images, videos) is often included with authoring tools for the convenience of the author. When this content conforms to WCAG, it is more convenient for authors and more easily reused.

Techniques: Implementation Techniques for Checkpoint 2.4

Success Criteria:

1. Any authoring tool that provides Web content (e.g. templates, clip art, multimedia objects, scripts, applets, example pages, etc.) that is bundled with the authoring tool or preferentially licensed (i.e. provided for free or sold at a discount) to the users of the authoring tool (as compared to non-users of that tool), then all of that Web content must always conform to WCAG (determine level).

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

Actions may be taken at the author's initiative that may result in accessibility problems. The authoring tool should include features that provide support and guidance to the author in these situations, so that accessible authoring practices can be followed and accessible web content can be produced.

This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives without author consent (Checkpoint 3.4). The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries (Checkpoint 3.6).

Accessibility-related documentation provides support and guidance to the author. The documentation must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7) and ensuring that documentation demonstrates authoring practices (Checkpoint 3.8) and workflow processes that result in accessible content (Checkpoint 3.9).

3.1 Prompt and assist the author to create content that conforms to WCAG. [Web Content Checkpoints Relative to WCAG]

Rationale: Appropriate assistance should increase the likelihood that typical authors will create content that conforms to WCAG. 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

Success Criteria:

1. When content is added that requires information from the author in order to conform to WCAG, then the authoring tool must inform the author that this additional information is required (e.g. via input dialogs, interactive feedback, etc.). (determine level)
2. If the authoring tool recommends a particular authoring practice then that practice must result in Web content that conforms to WCAG.

3.2 Check for and inform the author of accessibility problems. [Web Content Checkpoints Relative to WCAG]

Rationale: Authors may not notice or be able to identify accessibility problems. The tool can assist in their identification.

Note: This checkpoint does not apply to authoring tools that constrain authoring choice to such a degree that it is not possible to create Web content that does not conform to WCAG.

Techniques: Implementation Techniques for Checkpoint 3.2

Success Criteria:

1. The authoring tool must always provide a check (automated check, semi-automated check or manual check) for each applicable requirement of WCAG (determine level).
2. The authoring tool must alert the author to any failed check results prior to completion of authoring.

3.3 Assist authors in repairing accessibility problems. [Web Content Checkpoints Relative to WCAG]

Rationale: Assistance by the tool may simplify the task of repairing accessibility problems for some authors, and make it possible for others.

Techniques: Implementation Techniques for Checkpoint 3.3

Success Criteria:

1. The authoring tool must always provide a repair (automated repair, semi-automated repair or manual repair) for each applicable requirement of WCAG (determine level).
2. For manual repairs, the instructions for making a particular repair must be directly linked from the corresponding check.

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

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.5 Provide functionality for managing, editing, and reusing alternative equivalents. [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

Success Criteria:

1. The authoring tool must always keep a record of equivalent alternatives that the author inserts for particular non-text objects in a way that allows the text equivalent to be offered back to the author for modification and re-use if the same non-text object is reused.

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

Rationale: This summary will help the author to improve the accessibility status of their work, keep track of problems, and monitor progress.

Techniques: Implementation Techniques for Checkpoint 3.6

Success Criteria:

1. The authoring tool must provide an option to view a list of all known accessibility problems (i.e. detected by automated check or identified by the author as part of a semi-automated or manual check) prior to completion of authoring.

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

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

Techniques: Implementation 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.

3.8 Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 3]

Rationale: If accessible authoring is integrated into instruction and guidance offered by the tool (e.g. documentation, help, tutorials, examples, and workflow processes), authors are more likely to follow accessible authoring as a common practice. This reinforces the message of accessibility that is being promoted and facilitates a better understanding of the reasoning behind its use and its consequences. Authors are also more likely to use features that promote accessibility if they understand when and how to use them.

Techniques: Implementation Techniques for Checkpoint 3.8

Success Criteria:

1. All examples of markup and screenshots of the authoring interface that appear in the documentation and help must model content that conforms to WCAG.

3.9 Provide a tutorial on the process of accessible authoring. [Priority 3]

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

Techniques: Implementation Techniques for Checkpoint 3.9

Success Criteria:

1. Provide a tutorial on accessible authoring for that authoring tool.

GUIDELINE 4: Promote and integrate accessibility solutions

This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document. The checkpoint requirements for this section include ensuring that accessibility practices and features are given authoring interface priority (Checkpoint 4.1), clear availability (Checkpoint 4.2), workflow integration (Checkpoint 4.3), natural integration with the appearance and interactive style of the tool (Checkpoint 4.4), and sufficient configurability (Checkpoint 4.5).

4.1 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.1

Success Criteria:

1. When the author has more than one markup implementation to choose from (e.g. the color of text can be changed with presentation markup or style sheets), those markup implementations that meet the requirements of WCAG must have equal or higher prominence than those markup implementations that do not meet the WCAG requirements.

4.2 Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author [Priority 2]

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

Techniques: Implementation Techniques for Checkpoint 4.2

Success Criteria:

1. All accessibility prompting, checking, repair functions and documentation must meet the following conditions:
   1. if they are continuously active, then it must always be enabled by default and if the author disables it (e.g. from a preferences screen), then the tool must always inform the author that this may allow accessibility problems to be introduced.
   2. they must have at least the same prominence as the same type of function (i.e. prompting, checking, repair and documentation) related to other kinds of information (e.g. markup validity, program code syntax, etc.) .

4.3. Ensure that accessibility prompting, checking, repair functions, and documentation are integrated into the workflow of Web content development. [Priority 2] @@should we change "workflow" to "decision-making or action sequencing" features@@

Rationale: Accessible design as an afterthought or separate process is much more onerous and therefore costly than when accessibility is considered from the start. If the authoring tool supports a workflow in which the author considers accessibility before and/or during the authoring process it is more likely that accessible authoring practices will become a common practice. This is analogous to internationalization, which is much easier when it is considered from the beginning rather than handled last.

Techniques: Implementation Techniques for Checkpoint 4.3

Success Criteria:

1. Accessibility prompting must be integrated into all features that assist with author decision-making (e.g. templates, wizards, and instruction text). Accessibility checking, repair, and documentation functions must be made available before completion of any authoring workflow. @@agreed on Aug. 2 Call@@
2. Any mechanism that guides the author in sequencing authoring actions (e.g. design aids, wizards, templates, etc.) must integrate accessibility prompting, checking, repair functions, and documentation. @@are both criteria needed?@@
3. Any authoring tool features that assist the author with decision-making or action sequencing (e.g. wizards, templates, design aids, instruction text, etc.) must always integrate links to accessibility prompting, checking, repair functions and documentation. The integration must precede any crucial decision points, especially the completion of authoring.

4.5 Ensure that accessibility prompting, checking, repair functions and documentation are configurable [Priority 3]

Rationale: A configurable tool is more likely to be adaptable to the work habits of more authors.

Techniques: Implementation Techniques for Checkpoint 4.5

Success Criteria:

1. All functions related to accessibility prompting, checking, repair, and documentation must match the other prompting, checking, repair, and documentation functions of the tool (respectively), in terms of the number of options controllable by the author and the degree to which each option can be controlled.

@@STUFF THAT WE ARE STILL CONTEMPLATING@@

Checkpoint 4.3

4.4 Ensure that accessibility prompting, checking, repair functions, and documentation are naturally integrated into the appearance and interactive style of the tool. [Priority 3] @@Bob has very serious reservations to all of this@@

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

Techniques: Implementation Techniques for Checkpoint 4.4

Success Criteria:

1. The authoring interface for accessibility prompting, checking, repair, and documentation must match the authoring interface for comparable functions in terms of the following characteristics: (1) visual design (measured by design metaphors, artistic sophistication, sizes, fonts, colors), (2) operation (measured by degree of automation, number of actions for activation), and (3) comprehensiveness (measured by breadth and depth of functionality coverage).
2. All authoring tool interfaces for accessibility prompting, checking, repair functions and documentation must always match the authoring tool interfaces of the same type of function (i.e. prompting, checking, repair and documentation) related to other kinds of information (e.g. markup validity, program code syntax, etc.), in terms of the following characteristics:
   1. visual design (measured by design metaphors, artistic sophistication, sizes, fontfaces, colors),
   2. operation (measured by degree of automation, number of actions for activation, @@UI conventions@@), and
   3. comprehensiveness (measured by breadth and depth of functionality coverage).

The checkpoint priority levels used in ATAG 2.0 are:

Priority 1:

Priority 2:

• For Guideline 1 checkpoints: If the authoring tool does not satisfy this checkpoint, one or more groups of authors with disabilities will find it difficult to author for the Web.
• For Guideline 2, 3, 4 checkpoints: The checkpoint is important for authors using the authoring tool to create Web content that conforms to WCAG.

Priority 3:

• For Guideline 1 checkpoints: If the authoring tool does not satisfy this checkpoint, one or more groups of authors with disabilities will find it inefficient to author for the Web.
• For Guideline 2, 3, 4 checkpoints: The checkpoint is beneficial for authors using the authoring tool to create Web content that conforms to WCAG.

Relative Priority Checkpoints (3 types): The importance of these checkpoints depends on the requirements of external documents.

• Web Content Checkpoints Relative to WCAG: These checkpoints can be met to one of three levels:
  • Level 1:
    • WCAG 1.0: The Web content conforms to WCAG 1.0 Level "A". (i.e. all Priority 1 checkpoints are satisfied)
    • WCAG 2.0: The Web content conforms to WCAG 2.0 Level "A". (i.e. all level 1 success criteria for all guidelines have been met)
  • Level 2:
    • WCAG 1.0: The Web content conforms to WCAG 1.0 Level "Double-A". (i.e. all Priority 1 and Priority 2 checkpoints are satisfied)
    • WCAG 2.0: The Web content conforms to "WCAG 2.0 Level AA". (i.e. all level 1 and 2 success criteria for all guidelines have been met)
  • Level 3:
    • WCAG 1.0: The Web content conforms to WCAG 1.0 Level "Triple-A". (i.e. all Priority 1, Priority 2, and Priority 3 checkpoints are satisfied)
    • WCAG 2.0: The Web content conforms to "WCAG 2.0 Level AAA". (i.e. all level 1, 2, and 3 success criteria for all guidelines have been met)
• Authoring Interface Checkpoints Relative to WCAG: These checkpoints can be met to one of three levels:
  • Level 1:
    • WCAG 1.0: The authoring interface conforms to WCAG 1.0 Level "A". (i.e. all Priority 1 checkpoints are satisfied)
    • WCAG 2.0: The authoring interface conforms to "WCAG 2.0 Level A". (i.e. all level 1 success criteria for all guidelines have been met)
  • Level 2:
    • WCAG 1.0: The authoring interface conforms to WCAG 1.0 Level "Double-A". (i.e. all Priority 1 and Priority 2 checkpoints are satisfied)
    • WCAG 2.0: The authoring interface conforms to "WCAG 2.0 Level AA". (i.e. all level 1 and 2 success criteria for all guidelines have been met)
  • Level 3:
    • WCAG 1.0: The authoring interface conforms to WCAG 1.0 Level "Triple-A". (i.e. all Priority 1, Priority 2, and Priority 3 checkpoints are satisfied)
    • WCAG 2.0: The authoring interface conforms to "WCAG 2.0 Level AAA". (i.e. all level 1, 2, and 3 success criteria for all guidelines have been met)
• Authoring Interface Checkpoints Relative to ISO16071: These checkpoints can be met to one of three levels:
  • Level 1:
    • The authoring interface meets guidelines designated as "application", or "core" in Part @@???@@ of ISO TS 16071:2003.
  • Level 2:
    • The authoring interface meets guidelines designated as "application", "core", or "primary" in Part @@???@@ of ISO TS 16071:2003.
  • Level 3:
    • The authoring interface meets guidelines designated as "application", "core", "primary", or "secondary" in Part @@???@@ of ISO TS 16071:2003.

3.2 Claiming Conformance:

An ATAG 2.0 conformance claim must include a description of how the authoring tool meets each of the checkpoints that are required for the conformance level specified by the conformance profile. In the case of relative priority checkpoints, this description is required to be a point-by-point accounting of the requirements in the external document. A checkpoint is considered to have been met when the tool satisfies all of the normative success criteria listed for that checkpoint.