Guideline 6. Provide methods of checking and correcting inaccessible content

Many authoring tools allow authors to create documents with little or no knowledge about the underlying markup. To ensure accessibility, authoring tools must be designed so that they may automatically identify inaccessible content, and enable its correction even when the markup itself is hidden from the author.

In supporting the creation of accessible Web content, authoring tools should take into account the differing authoring styles of their users. In general, authors will prefer to be able to configure their tools to support their working style. Tools that allow such configuration can help authors to feel that accessible authoring is a natural practise (see also the previous guideline) rather than a tiresome intrusion on their normal work pattern. For example some users may prefer to be alerted to problems when they occur, whereas others may prefer to perform a check after the document is completed. This is analogous to programming environments that allow users to decide whether to check for correct code during editing or at compile time.

Note that valid markup is an accessibility requirement, particularly because it supports interoperability of assistive technologies (see also guideline 2 - Generate Standard Markup).

Checkpoints:

6.1 Check for and alert the author to accessibility problems. (Priority 1 for accessibility problems that are [Web-Content-Priority-1], Priority 2 for accessibility problems that are [Web-Content-Priority-2], Priority 3 for accessibility problems that are [Web-Content-Priority-3])

• Highlight accessibility problems by applying an error class and allow the user to declare presentation rules in the local (user) style sheet, either through direct CSS editing or via a wizard or menu interface.
• Highlight problems detected when documents are opened, when an editing or insertion action is completed, while an author is editing.
• Allow users to choose different alert levels based on the priority of authoring accessibility recommendations.
• If interruptive warnings are used, provide a means for the author to quickly set the warning to non-obtrusive to avoid frustration.
• Where there is a change in the character set (or subset) used, prompt the author to identify whether there has been a change in language
• Alert authors to accessibility problems when saving.
• Access concerns can be highlighted using strategies similar to spell checking within a word processor. Access alerts within the document can be linked to context sensitive help.
• A view that renders the document as it might appear without technologies such as style sheets and images enabled, or the ability to turn those features off and on in the editing view, will give an author some idea of whether a document's logical order has been correctly preserved, whether alternative text is appropriate, etc.
• The WAI Evaluation and Repair group [WAI-ER] is developing a document that discusses which aspects of the Web Content Accessibility Guidelines can be automatically tested. A draft of that document is available [Auto-test].

6.2 Assist authors in correcting accessibility problems. (Priority 1 for accessibility problems that are [Web-Content-Priority-1], Priority 2 for accessibility problems that are [Web-Content-Priority-2], Priority 3 for accessibility problems that are [Web-Content-Priority-3])

• Do this in a way that is consistent with the look and feel of the authoring tool.
• Provide context sensitive-help for accessibility errors. See also 7 Promote accessibility in help and documentation
• Where there are site-wide errors, to make correction more efficient the author can be given the choice 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 alt text that is appropriate for one use of na image but completely inappropriate for the other uses of the image on the same site (or even the same page).
• Allow authors to control both the nature and timing of the correction process.

6.4 Allow the author to override any removal of unrecognized markup. [Priority 2]

Notes:

1. The author may have included or imported markup that is not recognized by the tool, but which enhances accessibility.
2. This need not be the default setting.

• Provide options for the author to confirm or override removals on a change-by-change or as a batch process
• Provide a summary of all automated structural changes that may affect accessibility.
• Do not change the DTD without notifying the author.

6.5 Provide the author with a summary of the document accessibility status on a configurable schedule. [Priority 3]

• Provide a summary of accessibility problems remaining by type and/or by number.

6.6 Allow the author to perform element transformations. [Priority 3]

For example, to transform visually formatted elements to structure elements, or tables to lists.

• Allow the user to define transformations for imported documents that have presentation, rather than structural, markup.
• Allow the user 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, and to transform (deprecated) presentation HTML into style sheets.
• Remember that accessibility information, including attributes or properties of the elements being transformed, must be preserved - see 3.4