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].
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]