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]