Appendix ?: Techniques for User Prompting

The ATAG guidelines often refer to the practice of prompting and to a lesser extent alerting The following guidelines and selected checkpoints make explicit use of them:

• Guideline 3 (Support the creation of accessible content)
  ...prompting authors to include equivalent alternative information such as text equivalents, captions,
  and auditory descriptions at appropriate times can greatly ease the burden for authors....
  • 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....
• Guideline 4 (Provide ways of checking and correcting inaccessible content)
  • 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.

The importance of these concepts in the document and a perceived ambiguity of their meanings has been identified as a source of confusion.  This appendix will attempt to clarify the issue.

1. What is meant by prompting?

The word prompting is used in the document to denote all user interface methods by which the author is given an opportunity to add accessible content.  The following are responses to concerns raised by developers.

• There is no requirement that prompting be modal.  In other words, the author should not necessarily be prevented from performing other tasks.
• There is no requirement that prompting be dedicated to one accessibility issue.  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.

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])

2. User configurable prompting schedule

A user configurable schedule allows individual authors to determine, to some extent, how and when they will be prompted about accessibility issues.  For example, authors should have control stringence of the checks (i.e. WCAG level A, AA or AAA) and the scheduling of explicit prompts (i.e. as problems occur or at the completion of authoring). Of course, the extent of this configurability should be determined by developers on and individual basis. 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.

Supporting Reference:

Authoring tool support for the creation of accessible Web content should account for different authoring styles. Authors who can configure the tool's accessibility features to support their regular work patterns are more likely to accept accessible authoring practices (refer to guideline 5). 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.

(source: Guideline 4 Introductory Text)

Sample:

In Microsoft Word 97, spelling errors can be flagged and corrected in several ways depending on the preferences that the author has set on the spelling property card. Below is a screen shot of this card:

3. Limits to Prompting

[ed. Maybe we put some notes here about what sorts of things can and cannot be prompted for]

4. Types of Prompting

Most authoring tools will have ways of conveying information to users and collecting information in return.  These methods vary according to factors such as the design of the tool and the user interface conventions for its platform. The following is relatively generic overview of how these methods can be used for accessibility prompting.

Prompts

Prompts are basically requests for information. On most GUI platforms prompts take the form of dialog boxes that request information from the user.  Prompts can be used to encourage authors to provide information needed to make the content accessible (such as alternative text equivalents). For example, a text equivalent entry field prominently displayed in an image insertion dialog would constitute a prompt. Prompts are relatively unintrusive and address a problem before it arises. However, once the author has ignored the prompt, its message is unavailable. In the example below, Allaire Homesite prompts the user to enter Alt. Text by including this property within dialog that is displayed during image insertion. Although the dialog itself is in some sense intrusive, the inclusion of the Alt. Text field, once the dialog is displayed, would not be considered intrusive.

The next example demonstrates how attention might be drawn more explicitly to a prompt field. In this case, the author did not add Alt. Text when they first inserted the image. As a result, when the author edits the tag later, symbolic, textual and coloration changes highlight the problem.

Alerts

Alerts warn the author that there are problems that need to be addressed. The art of attracting the author's attention is a tricky issue. The way authors are alerted, prompted, or warned can influence their view of the tool and even their opinion of accessible authoring. Refer also to guideline 5.

Intrusive Alerts

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. The following screenshot shows an example of an intrusive alert that might be displayed if the author fails to enter Alt-text at an image insetion prompt.

Unintrusive Alerts

Unintrusive alerts are alerts such as icons, underlines, and gentle sounds that can be presented to the author without necessitating immediate action. For example, in some word processors misspelled text is highlighted without forcing the author to make immediate corrections. These alerts allow authors to continue editing with the knowledge that problems will be easy to identify at a later time. However, authors may choose to ignore the alerts altogether.