Techniques for Authoring Tool Accessibility Guidelines 1.0

ATAG Checkpoint 4.1: Check for and inform the author of accessibility problems. [Relative Priority]

Note: Accessibility problems should be detected automatically where possible. Where this is not possible, the tool may need to prompt the author to make decisions or to manually check for certain types of problems.

Techniques:

• See AERT document for evaluation and repair algorithms.
• Highlight problems detected when documents are opened, when an editing or insertion action is completed, or while an author is editing. Using CSS classes to indicate accessibility problems will enable the author to easily configure the presentation of errors.
• Alert authors to accessibility problems when saving.
• Accessibility problems can be highlighted using strategies similar to spell checking within a word processor. Accessibility alerts within the document can be linked to context sensitive help. Refer also to checkpoint 4.2.
• Where the tools cannot test for accessibility errors, provide the author with the necessary information, wizards, etc. to check for themselves.
• Include alerts for WCAG 1.0 [WCAG10] Priority 1 checkpoints in the default configuration.
• Provide an editing view that shows equivalent alternatives in the main content view to make it clear that they are necessary. This will make it obvious when they are missing.
• Allow authors to choose different alert levels based on the priority of authoring accessibility recommendations.
• If intrusive warnings are used, provide a means for the author to quickly set the warning to non-obtrusive to avoid frustration.

Reference:

• There are online tools whose output can be integrated with the user interface. Other tools are available for incorporation in existing software, either as licensed products or in some cases as "open source" solutions. The WAI Evaluation and Repair group maintains information about available tools [WAI-ER].
• The Web Accessibility Initiative's Protocols and Formats group have a draft set of notes about creating accessible markup languages [XMLGL].

ATAG Checkpoint 4.2: Assist authors in correcting accessibility problems. [Relative Priority]

Techniques:

• At a minimum, provide context-sensitive help with the accessibility checking required by checkpoint 4.1.
• Where there are site-wide errors, to make correction more efficient, allow the author to make site-wide changes or corrections. For example, this may be appropriate for a common error in markup, but may not be appropriate in providing a text equivalent that is appropriate for one use of an image but completely inappropriate for the other uses of the image on the same site (or even the same page).
• Assist authors in ways that are consistent with the look and feel of the authoring tool (See ATAG 5.1).
• Allow authors to control both the nature and timing of the correction process.
• Provide a mechanism for authors to navigate sequentially among uncorrected accessibility errors (See ATAG 7.4).

ATAG Checkpoint 4.3: Allow the author to preserve markup not recognized by the tool. [Priority 2]

Note: The author may have included or imported markup that enhances accessibility but is not recognized by the tool.

Techniques:

• If possible, preserve all unrecognized markup, since it might be related to accessibility (See ATAG 1.2).
• If changes to markup that is not recognized by the tool are necessary for the tool to further process the document (for example, a tool that requires valid markup when a document is opened), inform the author.
• Provide options for the author to confirm or override removal of markup on a change-by-change basis or as a batch process.
• Do not change the DTD without notifying the author.

ATAG Checkpoint 4.4: Provide the author with a summary of the document's accessibility status. [Priority 3]

Techniques:

• Provide a list of all accessibility errors found in a Web page.
• Provide a summary of accessibility problems remaining by type and/or by number.

ATAG Checkpoint 4.5: Allow the author to transform presentation markup that is misused to convey structure into structural markup, and to transform presentation markup used for style into style sheets. [Priority 3]

Techniques:

• Allow the author to define transformations for imported documents that have presentation, rather than structural, markup.
• Remember that accessibility information, including attributes or properties of the elements being transformed, must be preserved - see checkpoint 1.2.
• Some examples of transformations include:
  • Implementing XSLT in the tool.
  • HTML: table-based layout into CSS.
  • HTML: BR to the P element.
  • HTML: (deprecated) FONT into heuristically or author-determined structure.
  • Word processor styles to Web styles.
  • HTML: deprecated presentational markup into CSS.
  • XHTML: span into ruby.
  • MathML: presentational markup to semantic markup.
• Implement XSLT [XSLT] together with a user-interface for expressing transformations (see ATAG 2.1).
• Allow the author to create style rules based on the formatting properties of an element, and then apply the rule to other elements in the document, to assist conversion of documents to the use of style sheets.
• Include pre-written transformations to rationalize multiple tables
• transform (deprecated) presentation HTML into style sheets.

[previous] [top of this page] [contents] [next]