Instances of the term "prompting"
The term "prompting" appears in the following locations in the authoring
tool guidelines.
- Guideline
3 : Support the creation of accessible content.
"... authoring tool developers should attempt to facilitate and automate
the mechanics of [producing equivalent information]. For example,
prompting authors to include equivalent alternative
information such as text equivalents, captions, and auditory descriptions
..."
- Checkpoint 3.1 : Prompt the author to
provide equivalent alternative information (e.g., captions, auditory
descriptions, and collated text transcripts for video). [Relative
Priority]
- Checkpoint 3.4: Do not automatically
generate equivalent alternatives. Do not reuse previously authored
alternatives without author confirmation, except when the function is
known with certainty. [Priority 1]
"For example, prompt the author for a text equivalent of
an image..."
- Checkpoint 4.1: (Check for and inform the
author of accessibility problems. [Relative Priority]
"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."
Unfotuantely, a potential ambiguity in the meaning of the term has been
identified. This section will attempt to clarify the issue. Also, remember
that although the following guidelines and checkpoints make explicit use of
the term, other guidelines may be best implemented using some form of
prompting as well.
The term "prompting" is used in the document to denote all user interface
methods by which the author is given an opportunity to add accessible content.
Developers are often concerned that prompting requires them change their
products in ways that their users will not accept. To address these concerns
the following statements should make clear, what prompting is not:
- Prompting does not need to be modal: In other words,
the author should not necessarily be prevented from performing other tasks
when accessibility problems exist.
- There is no requirement that prompting be implemented
with a one prompt per accessibility issue system. In other words, the
author may be presented with a number of issues within one prompt, only
one or several of which may relate to accessibility.
- There is no requirement that prompting be inflexible. A
user-flexible schedule should be an important component of the system. The
degree of flexibility should be determined by the nature of the tool.
- There is no requirement that prompting change the
fundamental look and feel of a tool. In fact, as a general rule, the
implementation of prompting should be governed by checkpoint
5.1 (Ensure that functionality related to accessible authoring
practices is naturally integrated into the overall look and feel of the
tool. [Priority 2])
Authoring tool support for the creation of accessible Web content should
account for different authoring styles. When authors are able to configure the
tool's accessibility features to support their regular work patterns, they
will be more likely to accept accessible authoring practices (ATAG
Checkpoint 5.1). For example, some authors may prefer to be alerted to
accessibility problems when they occur, whereas others may prefer to perform a
check at the end of an editing session. This is analogous to programming
environments that allow users to decide whether to check for correct code
during editing or at compilation.
A user configurable schedule allows individual authors to determine how and
when they will be prompted about accessibility issues. For example, authors
should have control over the stringency of the checks (i.e. WCAG conformance
level) and the scheduling of prompting (i.e. as problems occur, following
saves, or prior to Web publishing). Of course, the extent of this
configurability should be appropriate to each tool, as determined by the
developer. Some tool developers may decide to restrict authors to several
global settings, while others might allow authors to make fine grained
distinctions, such as different scheduling for different types of problems.
For example, in Microsoft Word 2000, spelling errors can be flagged and
corrected in several ways depending on the preferences that the author has set
on the "Spelling & Grammar" property card (Figure A-1).
All authoring tools will have ways of conveying information to users and
collecting information in return. These methods vary according to the design
of the tool and the user interface conventions for the platform upon which it
is implemented. For the sake of this document we have attempted to divide the
methods roughly between prompts and alerts. The following is relatively
generic overview of how these methods can be used for accessibility prompting.
Keep in mind that these categories may overlap. For example, an intrusive
alert may contain a prompt edit field.
Prompts are interface mechanisms that request information from the user, or
at least provide an opportunity for user to provide information if they wish.
On most GUI platforms, prompts commonly take the form of dialog box controls.
The author answers the requests by modifying the states of the controls (i.e.
typing text in a textbox or selecting a checkbox).
A prompt can be viewed as either intrusive or unintrusive depending on
whether the user has requested that it be displayed or not. For example, when
the author activates the "Save As..." menu item, an unintrusive dialog is
typically displayed to prompt the user for a file name and location. On the
other hand, if the user presses activates the "Save" command and the program
detects a problem (ex. saving to a media that has been removed), an intrusive
dialog is usually displayed prompting the user to replace the media or select
a new saving location.
The main drawback of using unintrusive prompts for ensuring accessible
authoring is that once the author has dismissed the prompt, its message is
unavailable unless the user requests it again. This may be avoided by the use
of intrusive prompts, however, displaying too many of these can quickly annoy
the author and one of the goals of this document is to suggest techniques for
implementing ATAG that preserve author cooperation.
Therefore, when implementing the ATAG, unintrusive prompts are recommended
to encourage authors to provide information required for accessibility when
the user inserts or inspects an element. For example, in the case of HTML, a
prominently displayed alt-text entry field in an image insertion dialog, would
constitute a prompt (Figure A-3).
In ATAG, the interface priority of controls related to accessibility is
governed by ATAG
checkpoint 5.2 (Ensure that accessible authoring practices supporting Web
Content Accessibility Guidelines 1.0 [WCAG10] Priority 1 checkpoints are among
the most obvious and easily initiated by the author. [Priority 2]). This
checkpoint does not require that accessibility concerns
obscure the other editing tasks. The checkpoint merely emphasizes that these
controls should be allotted screen presence that is appropriate for their
importance. For example, in Macromedia's Dreamweaver 2 HTML authoring tool, a
property toolbar is displayed with fields that are appropriate to the
currently selected element. In some cases, including the image element, the
author can toggle the toolbar between a limited and extended set of
properties. Due to the importance of the alt attribute, it is
recommended that the edit field for this property be available in the limited
set. In the case of Dreamweaver, this is precisely what has been done (Figure
A-2).
Conformance with checkpoint 5.2 may be reinforced by visually highlighting
accessibility features with colour, icons, underlining, etc. For example, in
Allaire's HomeSite authoring tool, attention is drawn more explicitly to
accessibility-related prompt fields. In this case, the HomeSite tag editor
dialog contains symbols, colour changes and explanatory text that highlight
the alt-text field and remind the author that it is required for HTML 4.0 and
necessary for accessibility.
Sometimes several editing tasks are required to make a single element
accessible. Instead of dispersing these prompts over multiple dialog boxes, it
may be more effective to draw them together into one group of controls. In the
following example from Allaire HomeSite, the prompt fields pertaining to
multiple accessibility requirements of the HTML input form control (i.e.
Access Key, Tab Index, Title and Label Text) are organized into the same
dialog box.
In cases where there are many pieces of information required, authors may
benefit from a sequential presentation of prompts. This technique usually
takes the form of a wizard or a checker. In the case of a wizard, complex
interactions are broken down into a series of simple steps. The later steps
can then be updated on the fly to take into account 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,
Microsoft Word 2000 has a checker that displays all the spelling and grammar
problems one at a time (Figure A-5). Notice how all the problems are displayed
in a standard way: type of problem (i.e. "not in dictionary"), the problem
instance (i.e. "There are a few spellling mistakes") and suggested fixes (i.e.
a list of suggested correct words). The user also has several correcting
options, some of which can store responses to affect how the same situation is
handled later.
In an accessibility checker, the same is true, however the dialog template
has to be somewhat more flexible since the problems can range from a missing
text string for a multimedia object to missing structural information for a
table to improper use of colour. In the following example, from A-Prompt, the
author is prompted to add alternate text for an image as part of a correction
run. Notice that, like the spell checker, the prompt includes a statement of
the problem (i.e. "missing alternate text for an image"), the problem instance
(i.e. earthrise.gif), and suggested fixes (i.e. a suggestion from the alt-text
registry, "An earth-rise as seen from the surface of the moon"). In addition,
the dialog also has some instructive text to aid the author in writing text if
necessary.
Alerts warn the author that there are problems that need to be addressed.
Since addressing these problems usually requires adding information, it may be
argued that the distinction between an alert (warning) and a prompt
(information request) is confusing. For the purpose of this document, an alert
is essentially a warning without an immediate means (i.e. a text box) for
adding the missing information (although a well-designed warning should link
intuitively to a prompt wherever possible), whereas a prompt is an opportunity
to add missing information that may or may not include a warning. Still
confused? Fortunately, in general, it doesn't really matter as long as the
tool succeeds in convincing authors to add the required information at some
point before Web publishing occurs.
Note: The method by which a tool attracts the author's
attention is a tricky issue because it can influence the author's view of the
tool and even their opinion of accessible authoring as a whole. That's why the
ATAG includes checkpoint
5.1 (Integrate accessibility solutions into the overall "look and feel"
[Priority 2]).
Intrusive alerts are informative messages that interrupt the editing
process for the author. For example, intrusive alerts are often presented when
an author's action could cause a loss of data. Intrusive alerts allow problems
to be brought to the author's attention immediately. However, authors may
resent the constant delays and forced actions. Many people prefer to finish
expressing an idea before returning to edit its format.
If the tool developer chooses to use intrusive alerts for some or all of
the alerts, the simplest implementation might to present the author with a
single option that channels them to a prompt where they may or may not be
forced to enter the missing information. This is not a recommended strategy.
Instead, the alert should include two or more options that linking to a prompt
for correcting the problem, an option to return directly to editing and
perhaps even a link to relevant help (Figure A-7). In addition, the author may
be presented with an option to prevent similar intrusive warnings in the
future.
Unintrusive alerts are interface methods such as icons, underlines, and
gentle sounds that can be presented to the author without requiring immediate
action. For example, in some authoring tools misspelled text is highlighted
within the document, identifying the location of problems without forcing the
author to make corrections immediately. As an example, Microsoft Word 2000
includes the option to underline spelling errors (Figure A-9) in red and
grammatical errors in green (for author accessibility the user must be able to
change the default presentation - users who are red-green colorblind, for
example, will not be able to perceive the information being conveyed by red
and green underlines). When the user right-clicks on the highlighted text,
they are presented with several correction options.
Although intrusive alerts are the least user-friendly form of prompting,
there are some situations in which they may become necessary. For example,
when the editing process is complete and publishing to the Web appears
imminent, unintrusive alerts are not an option since there is simply no
editing process left. This may always be the case when a document composed in
a proprietary (non-Web format) is being converted to a Web format for
publishing. This does not mean that unintrusive alerts are not also possible
in these situations. For example, an alert might be added directly to the
"Save" dialog (Figure A-8).
Another Microsoft product, FrontPage 2000, uses unintrusive alerts in its
HTML editing environment to indicate syntax errors. As the author types, the
syntax is automatically checked (Figure A-10). The system is unintrusive
because the author is allowed to make as many syntax errors as they like, but
the colour of the text signals that one or more errors have been made.
In the context of the Authoring Tool guidelines, these unintrusive alert
techniques could be used to indicate which parts of a document or site contain
accessibility problems. This will inform the author about the type and number
of errors without interrupting their editing process. Of course, these are
just two examples of the techniques that developers might choose. Other
implementations might include in-line icons as the BOBBY evaluation tool does
or even accessibility problem density displays for power users.
The downside of unintrusive alerts is that the author may choose to ignore
the alerts completely. Therefore, the optimum strategy might be to emphasize
unintrusive solutions until a critical point (i.e. publishing) at which time
an effective intrusive alert, such as a problem summary, can be displayed.
D
