ATAG20 Guidelines

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

Generally, the greater the degree of author control of authoring decisions, the greater the potential for the introduction of accessibility problems. Since different types of authoring tools differ greatly in the extent to which they automate authoring decisions, ????. Plain text editors automate very few decisions, tag-based editors may automate low level syntax but leave the arrangement of elements up to the user, while WYSIWYG editors may limit the author to providing semantic information only (i.e. text, images, etc.).

Guiding the author to produce accessible content:

Manually following accessibility authoring practices is not a trivial task for most authors. Authoring tool developers should attempt to facilitate and automate this process. 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 users to decide whether to check for correct code during editing or at compilation.

*NEW* 3.1 Assist the author to avoid accessibility problems when they add content or edit markup. [Relative Priority]

Rationale: Appropriate assistance should result in typical tool users following accessible authoring practices. Different tools will accomplish this goal in ways appropriate to their products, processes and users.

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

Success Criteria:

  1. The authoring tool suggests accessible authoring practices where appropriate.
  2. The authoring tool prompts (Important Definition) the typical author for information that cannot be generated automatically (e.g. equivalent alternatives (see Checkpoint 3.4).
  3. Prompt 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]

Rationale: Once accessibility problems are present, a means of detecting them will be necessary.

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

Success Criteria:

  1. Must provide at least one check (automated, semi-automated or manual) for each requirement of WCAG [WCAG].
  2. A typical author is made aware of accessibility problems within the document.
3.3 Assist authors in correcting accessibility problems. [Relative Priority]

Rationale: Once accessibility problems have been found, authors may need help to correct them properly.

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

Success Criteria:

  1. Context-sensitive help, semi-automated repairs or fully automated repairs are provided for each requirement of WCAG [WCAG].
  2. A typical author is able to successfully correct any identified accessibility problem.
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 interfere with accessibility checking.

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

Success Criteria:

  1. For new non-text objects, the tool prompts 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 typical author, there are no improperly generated alternatives.
3.5 Provide functionality for managing, editing, and reusing alternative equivalents for non-text 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.1 and Checkpoint 3.3.

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

Success Criteria:

  1. The tool recognizes when non-text objects have previously-authored alternative equivalents.
  2. A typical author is able to reuse these previously-authored authored alternative equivalents when non-text objects are reused.
3.6 Provide the author with a summary of the document's accessibility status. [Priority 3]

Rationale: A summary will allow authors to monitor the progress of their accessibility status and learning more about accessibility problems.

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

Success Criteria:

  1. A listing of the current accessibility problems is available.
  2. From the summary, the typical author will be to tell whether their content meets the accessibility standard in question.

Promoting accessibility in help and documentation:

Many authors will not be familiar with Web accessibility issues, while authors that are familiar with these issues may still 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: As with any feature, documentation of all the accessibility-related features of the tool (dialog boxes, utility, code views, etc.) will facilitate authors in finding and using them effectively.

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

Success Criteria:

  1. All features that help create accessible content are documented in the help system.
  2. 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.
3.8 Document the process of using the tool to produce accessible content. [Relative Priority]

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

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

Success Criteria:

  1. The documentation contains sample or suggested work flows which, if followed, are likely to increase the chance of higher levels of WCAG [WCAG] conformance than otherwise. 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 workarounds that are likely to achieve the same result.
  3. A typical author should be able to find and understand this workflow documentation.