Despite assistance from the tool (see Checkpoint
3.1), accessibility problems may still be introduced (e.g. by the author
during hand coding or content authored by other tools is imported). In these
cases, the assistance mechanisms that operate when markup is added or edited
(i.e insertion dialogs and property windows) must be backed up by a more
general checking system that can detect and alert the author to problems
anywhere within the content (attribute, element, programmatic object, etc.).
Ideally, checking mechanisms should be highly integrated with correction
mechanisms (see Checkpoint 3.3)
so that when the system detects a problem and informs tha author, the tool
also helps the author address the issue.
Levels of Automation:
Accessiblity checking may be achieved with varying levels of automation:
manual, semi-automated
and fully automated (preferred):
- Manual:
The tool provides the author with instructions for detecting a problem,
but does not automate the task of detecting the problem in any meaningul
way (see Figure 3.2.1). As a result, the author
must follow the instructions and make the determination that a problem
exists by themselves. This type of check is discouraged since it can be
annoying for the author, especially when the type of problem in question
may be easily detected by a more automated utility (e.g. an element missing
a particular attribute).
Figure
3.2.1: Example of a manual check. [d]
(Source: mockup by Jan Richard)
|
- Semi-Automated:
The tool is able to identify potential problems, but still requires a
human judgment by the author to make a final appraisal (see
Figure 3.2.2). This type of check is usually most appropriate for
semantic-type problems, such as descriptions of non-text objects, as opposed
to purely syntactic problems, such as missing attributes, which lend themselves
more readily to automation.
Figure:
3.2.2: Example of a semi-automated check. [d]
(Source: mockup by Jan Richards)
|
- Automated (Preferred):
The tool is able to check for accessibility problems automatically, with
no human intervention required (see Figure 3.2.3).
This type of check is usually appropriate for syntactic-type checks, such
as the use of deprecated elements or a missing attribute, in which the
meaning of text does not play a role.
Figure:
3.2.3: Example of a fully automated check. [d]
(Source: mockup by Jan Richards)
|
Timing Options for "Informing" the Author:
Accessiblity checking mechanisms may use make use of different timing options:
immediate interruption, negotiated interruption (preferred), and scheduled
interruption:
- Immediate Interruption:
An immediate interruption is the most intrusive timing option because
the author's attention is actively diverted from the current editing task
by the notification of some issue. This might be acheived, for instance,
by an alert dialog (see Figure 3.2.4). This type
of alert presents multiple usability problems, and should be used sparingly
because it interferes with the normal design workflow. Intrusive warnings
are probably only appropriate when the window of opportunity for correcting
a serious accessibility problem is about to close. An example of this
might be when an author is publishing a document to their site. In general,
we recommend using the less disruptive timing options.
Figure
3.2.4: Example of a dialog box making an immediate interruption.
[d]
(Source: mockup by Jan Richards)
|
- Negotiated Interruption
(Preferred): A negotiated interruption is caused by interface
mechanisms (icons, line or color highlighting of the element, audio feedback,
etc.) that alert the author to a problem, but are flexible as to whether
the author should take immediate action or address the issue at a later
stage in the design process. This type of unintrusive alert can be better
integrated into the design workflow. For example, a colored outline might
be drawn around offending objects in a WYSIWYG view (see Figure
3.2.5), while the markup text for the same object might be highlighted
by a different font color in the code view (see Figure
3.2.6). Besides being unintrusive, such indicators will have the added
benefit of informing the author about the distribution of errors within
the document without interrupting their editing process.Of course, some
authors may choose to ignore the alerts completely. In this case, the
AUWG does not recommend forcing the author to fix the problem.
Instead, it recommends that, at some major editing
event (e.g., when publishing), the tool should remind the author of
the continuing unresolved accessibility issues.
 Figure
3.2.5 (left): Example of inobtrusive highlighting in a WYSIWYG
editor. [d]
(Source: mockup by Jan Richards)
Figure 3.2.6
(right): Example of font color highlighting in a code view. [d]
(Source: mockup by Jan Richards) |
- Scheduled Interruption:
A scheduled interruption is one in which the author has set the tool to
alert them of accessibility issues on a configurable
schedule. One option for the schedule might be to have prompts associated
with the interface mechanisms for significant authoring events such as
saving, exiting, publishing, printing, etc.. At the significant authoring
event, the author would be informed of the problem, while at the same
time they would not be prevented from saving, publishing, printing,
etc.. For example, a "save as" dialog could display an accessibility warning
and an option to launch a correction utility after saving (see
Figure 3.2.7). A potential downside of this type of prompting is that
by the time the prompt is displayed (publishing, etc.), the author may
not have time to make the required changes, especially if they are extensive.
Figure
3.2.7: Example of a scheduled prompt included at the
bottom of a "save as" dialog. [d] (Source: mockup by
Jan Richards)
|
Other Techniques:
-
See AERT document for evaluation and repair algorithms. [T0186]The
WAI Evaluation and Repair group [WAI-ER] is developing a
document that discusses detailed techniques for testing the accessibility
of content according to the Web Content Accessibility Guidelines, and
methods of repairing it. A draft of that document is available [AUTO-TOOL].
-
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]
-
Alert authors to accessibility problems when saving. [T0188]
-
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. (See the Techniques for ATAG checkpoint 6.1) [T0189]
-
Where the tools cannot test for accessibility errors, provide the author
with the necessary information, wizards, etc. to check for themselves.
[T0190]
-
Include alerts for WCAG Priority 1
checkpoints in the default configuration. [T0191]
-
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]
-
Allow authors to choose different alert levels based on the priority of
authoring accessibility recommendations. [T0193]
-
If intrusive warnings are used, provide a means for the author to quickly
set the warning to non-obtrusive to avoid frustration. [T0194]
Reference:
- The WAI Evaluation and Repair group [WAI-ER] has produced a
Public Working Draft of techniques for evaluating and repairing HTML according
to WCAG 1.0 [AERT]. [T0195]
Once a problem has been detected by the author or, preferably, the tool
(see Checkpoint 3.2), the tool may
assist the author to correct the problem.
Levels of Automation:
As with accessibility checking, the extent to which accessibility correction
can be automated depends on the nature of the particular problems. Some
repairs are easily automated, whereas others that require human judgement
may be semi-automated at best. The categories of repair include:
- Manual:
The tool provides the author with instructions for making the necessary
repair, but does not automate the task in any meaningful way (i.e. the
tool may move the cursor to start of the problem). As a result, the author
must follow the instructions and make the repair by themselves. For example,
a tool might flag an
img
element as missing alt-text, but
leave it up to the author to add the appropriate markup and text string
(see Figure 3.3.1).
Figure
3.3.1: Example of a manual repair in a code view. The tool has
detected the problem and selected the offending element, but the
user must make the repair. [d]
(Source: mockup by Jan Richards)
|
- Semi-Automated:
For some types of problems, the tool may be able to help perform the repair,
but the author's input is still required. For example, the tool may prompt
the user for a plain text string, but then be capable of handling all
the markup required to add the text string to the content. In other cases,
the tool may be able to narrow the choice of repair options, but still
rely on the author to make the final selection (see
Figure 3.3.2).
Figure
3.3.2: Example of a semi-automated repair in a WYSIWYG editor.
The user has right-clicked on a highlighted object. The user must
then decide whether the suggested "alt" text is appropriate.
If the user decides that it is, the tool handles the details of
updating the markup. [d]
(Source: mockup by Jan Richards)
|
- Automated:
For some types of problems, tools may be is able to make repairs automatically.
For example, in cases where the user wishes to strip out every instance
of specific element (see Figure 3.3.3). In these
cases, very little, if any, user interface is required.
Figure
3.3.3: Since an automated repair might be completed with the user
interface, here is an example of an announcement that might follow
an automated repair. [d]
(Source: mockup by Jan Richards)
|
Special-Purpose Correcting Interfaces:
When problems require some human judgement, the simplest solution is often
to display the property editing mechanism for the offending element. This
has the advantage that the user is already somewhat familiar with the interface.
However, this practice suffers from the drawback that it does not necessarily
focus the author's attention on the dialog control(s) that are relevant
to the required correction. Another option is to display a special-purpose
correction utility (see Figure 3.3.4) that includes
only the input field(s) for the information currently required. The advantage
of this approach is that additional information and tips that the author
may require in order to properly provide the requested information can be
easily added. Notice that in the figure, a drop-down edit box has been used
for the alt-text field. This technique might be used to allow the author
to select from text strings used previously for the alt-text of this image
(see ATAG Checkpoint 3.5 for more).
Figure 3.3.4: Example
of special-purpose correction interface. [d]
(Source: mockup by Jan Richards based on A-Prompt)
|
Sequential Checking
In cases where there are likely to be many accessibility problems, it may
be useful to implement a checking utility that presents accessibility problems
and repair options in a sequential manner. This may take the a
form similar to a configuration wizard or a spell checker (see
Figure 3.3.5). In the case of a wizard, a complex interaction is broken
down into a series of simple sequential steps the user can complete one
at a time. The later steps can then be updated on the fly to take into account
the information provided by the user in earlier steps. A checker is a special
case of a wizard in which the number of detected errors determines the number
of steps. For example, word processors usually have checkers that display
all the spelling problems one at a time in a standard template with places
for the misspelled word, a list of suggested words, and the correct word.
The user also has correcting options, some of which can store responses
to affect how the same situation is handled later.
Figure 3.3.5: Example
of a sequential accessibility checker that incorporates the special-purpose
correction interface from Figure 3.3.4. [d]
(Source: mockup by Jan Richards based on A-Prompt)
|
In an accessibility problem checker, sequential prompting is an efficient
way of correcting problems. However, because of the wide range of problems
the checker needs to handle (i.e. missing text, missing structural information,
improper use of color, etc.), the interface template will need to be even
more flexible than that of a spell checker. Nevertheless, the template is
still likely to include areas for identifying the problem (WYSIWYG or markup-based
according to the target audience of the tool), suggesting multiple solutions
and choosing between or creating new solutions. In addition, the dialog
may include context-sensitive instructive text to help the author with the
current correction.
Real-Time (Live) Authoring
When authoring tools produce content in real-time, the luxury of prompting
on a user configurable schedule is to a large degree lost. At the same time,
due to the time pressure, authors in real-time environments tend to be less
receptive to intrusive prompts. Nevertheless, tools that allow this kind
of authoring (see Figure 3.3.6) should still take
accessibility issues into account by supporting the following:
- Determination of Participant Requirements:
If a real-time communication takes place between individuals with no special
communicative needs, there may be no need for real-time prompting. However,
the author may not personally know all the special communicative needs
of the participants (even if the author knows everyone personally). The
tool might be able to facilitate a decision about whether supplements
need to be provided by asking participants which types of supplemental
material they wish to have made available (see "Request whiteboard
descriptions" checkbox in the figure). and then prompt the author
(or see Assistant Author) to provide these (preferably
during Preparation Time). In cases when it is
not possible to know the needs of everyone participating in a communication,
the tool should assume there are unidentified users with disabilities.
Moreover, even if there are no individuals with special communicative
needs participating in the original real-time communication, if the communication
is archived there will always be a possibility that future
users will experience accessibility problems with the material. Therefore,
even when it has been determined that the original communication does
not require supplements, if the author chooses to archive the communication,
the authoring tool should guide the author through a configurable interruption
process to check for and repair accessibility problems after the real-time
session has ended, but prior to archiving.
- Assistant Author:
In some cases, it may be possible to designate a secondary author in the
live community, who can receive and respond to the intrusive prompts for
supplemental information generated as the primary author proceeds uninterrupted.
The secondary author might be an unrelated specialist, analogous to Sign
language interpreter, or a co-author (helpful for describing technical
drawings, etc.).
- Preparation Time:
If the authoring tool allows the author time to pre-assemble materials
for a live presentation (e.g. a professor preparing for an online class),
this authoring is not considered real-time authoring. The authoring tool
has the opportunity to provide both intrusive and unintrusive prompts
and alerts as described elsewhere in this document. For example, when
the professor imports an image to be used in her lecture, she could be
prompted to provide an alternative representation of that image.
Figure
3.3.6: Real-time presentation in a Whiteboard/Chat environment. Notice
the functionality for requesting
whiteboard descriptions, volunteering to be the secondary author (describer),
and describing a whiteboard object even as the dialog continues. d (Source: mockup by Jan Richards).
|
If it has been determined that the author must provide real-time supplements,
but no preparation time or assistant
author are available, then in addition to allowing the author control
of the nature and timing of prompting, the authoring tool can facilitate
the inclusion of supplements by:
- Implementing the equivalent alternatives management functionality (see
Checkpoint 3.5). This way, if the author uses an object that has been
used before, the tool can suggest the previously stored alternative, which
the author can quickly accept or decline without substantial workflow
disruption.
- Providing a voice recognition capability so that the author's real-time
speech input can be converted into captioning.
Other Techniques:
-
At a minimum, provide context-sensitive help with the accessibility checking
required by ATAG Checkpoint 3.2. [T0197]
-
Where a tool is able to detect site-wide errors, allow the author to make
site-wide 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]
-
Assist authors in ways that are consistent with the look and feel of the
authoring tool (See Techniques
for ATAG Checkpoint ?.?). [T0199]
-
Allow authors to configuration the nature and timing of the correction
process. [T0200]
-
Provide a mechanism for authors to navigate sequentially among uncorrected
accessibility errors. [T0201]
Reference:
- The WAI Evaluation and Repair group [WAI-ER] has produced a
Public Working Draft of techniques for evaluating and repairing HTML according
to WCAG 1.0 [AERT]. [T0195]