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.
@@How exactly should we handle the AERT?@@.
Techniques:
-
See AERT document for evaluation and repair algorithms. [T0186]
(Suggested)
- 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. [T0187]
(Suggested)
- Alert authors to accessibility problems when saving. [T0188]
(Suggested)
- 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. [T0189]
(Suggested)
- Where the tools cannot test for accessibility errors, provide the
author with the necessary information, wizards, etc. to check for themselves.
[T0190] (Suggested)
- Include alerts for WCAG 1.0 [WCAG10] Priority 1 checkpoints
in the default configuration. [T0191]
(Suggested)
- 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. [T0192]
(Suggested)
- Allow authors to choose different alert levels based on the priority
of authoring accessibility recommendations. [T0193]
(Suggested)
- If intrusive warnings are used, provide a means for the author to
quickly set the warning to non-obtrusive to avoid frustration. [T0194]
(Suggested)
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]. [T0195]
- The Web Accessibility Initiative's Protocols and Formats group have a draft
set of notes about creating accessible markup languages [XMLGL]. [T0196]
Techniques:
- At a minimum, provide context-sensitive help with the accessibility
checking required by checkpoint 4.1. [T0197]
(Suggested)
- 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). [T0198] (Suggested)
- Assist authors in ways that are consistent with the look and feel
of the authoring tool (See ATAG 5.1). [T0199]
(Suggested)
- Allow authors to control both the nature and timing of the correction
process. [T0200] (Suggested)
- Provide a mechanism for authors to navigate sequentially among uncorrected
accessibility errors (See ATAG 7.4).
[T0201] (Suggested)
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). [T0202]
(Highly Recommended) @@Use of "Highly Recommended"?@@
- 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. [T0203]
(Highly Recommended) @@Use of "Highly Recommended"?@@
- Provide options for the author to confirm or override removal of
markup on a change-by-change basis or as a batch process. [T0204]
(Suggested)
- Do not change the DTD without notifying the author. [T0206]
(Suggested)
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. [T0207]
(Highly Recommended) @@Use of "Highly Recommended"?@@
- Provide a summary of accessibility problems remaining by type and/or
by number. [T0208] (Suggested)
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. [T0209]
(Highly Recommended) @@Use of "Highly Recommended"?@@
- Remember that accessibility information, including attributes or properties
of the elements being transformed, must be preserved - see checkpoint 1.2. [T0210]
(Highly Recommended) @@Use of "Highly Recommended"?@@
- Some examples of transformations include [] (Suggested):
- T0211 Implementing XSLT in the tool.
- T0212 HTML: table-based layout into CSS.
- T0213 HTML:
BR to the P
element.
- T0214 HTML: (deprecated)
FONT
into heuristically or author-determined structure.
- T0215 Word processor styles to Web styles.
- T0216 HTML: deprecated presentational
markup into CSS.
- T0217 XHTML:
span into ruby.
- T0218 MathML: presentational markup to
semantic markup.
- Implement XSLT [XSLT] together with a user-interface for expressing transformations
(see ATAG 2.1). [T0219] (Suggested)
- 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. [T0220] (Suggested)
- Include pre-written transformations to rationalize multiple tables
- transform (deprecated) presentation HTML into style sheets. [T0221]
(Suggested)
[previous section] [top of this page]
[full techniques contents] [next]