- ATAG
4.1 Check
for and inform
the author of accessibility
problems. [Relative Priority] (Checkpoint
4.1)
- 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. In the section
below, the evaluation (ATAG 4.1) and repair (ATAG 4.2) techniques for
each WCAG checkpoint have been grouped together (but stil need to be
added here @@).
See AERT document for evaluation and repair algorithms.(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.(Suggested)
Alert authors to accessibility problems when saving.(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.(Suggested)
Where the tools cannot test for accessibility errors, provide the
author with the necessary information, wizards, etc. to check for
themselves.(Suggested)
Include alerts for WCAG 1.0 [WCAG10] Priority 1
checkpoints in the default configuration.(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.(Suggested)
Allow authors to choose different alert levels based on the priority of
authoring accessibility recommendations.(Suggested)
If intrusive warnings are used, provide a means for the author to
quickly set the warning to non-obtrusive to avoid
frustration.(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].
- The Web Accessibility Initiative's Protocols and Formats group
have a draft set of notes about creating accessible markup
languages [XMLGL].
- ATAG 4.2 Assist authors in
correcting accessibility
problems. [Relative Priority] (Checkpoint
4.2)
-
At a minimum, provide context-sensitive help with the accessibility
checking required by checkpoint 4.1.(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).(Suggested)
Assist authors in ways that are consistent with the look and feel of
the authoring tool (See ATAG 5.1).(Suggested)
Allow authors to control both the nature and timing of the correction
process.(Suggested)
Provide a mechanism for authors to navigate sequentially among
uncorrected accessibility errors (See ATAG
7.4).(Suggested)
- ATAG 4.3
Allow the author to preserve markup not recognized by the tool. [Priority 2] (Checkpoint
4.3)
- Note:
The author may have included or imported markup that enhances
accessibility but is not recognized by the tool.
If possible, preserve all unrecognized markup, since it might be
related to accessibility (See ATAG 1.2).[Required] @@
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.[Required] @@
Provide options for the author to confirm or override removal of markup
on a change-by-change basis or as a batch process.(Suggested)
Provide a summary of all automated structural changes that may affect
accessibility.(Suggested)
Do not change the DTD without notifying the author.(Suggested)
- ATAG
4.4 Provide the author with a summary of the document's
accessibility status. [Priority 3] (Checkpoint
4.4)
- Provide a list of all accessibility errors found in a Web page.[Required] @@
Provide a summary of accessibility problems remaining by type and/or
by number.(Suggested)
Sample(s):
- ATAG
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] (Checkpoint
4.5)
- Allow the author to define transformations for imported documents
that have presentation, rather than structural, markup.[Required] @@
Remember that accessibility information, including attributes or
properties of the elements being transformed, must be preserved - see
checkpoint 1.2.[Required]
@@
Some examples of transformations include (Suggested):
- 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).(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(Suggested)
Include pre-written transformations to rationalize multiple tables,
and to transform (deprecated) presentation HTML into style
sheets.(Suggested)