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 does ATAG mean 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 when accessibility problems exist.
• 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.

IMPORTANT NOTE: 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 over the stringency of the checks (i.e. WCAG level A, AA or AAA) and the scheduling of prompting (i.e. as problems occur or at the completion of authoring). Of course, the extent of this configurability should be determined by developers on an 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.

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

2.2 Example:

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. Types of Prompting

All 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. Keep in mind that these categories may overlap. For example, an intrusive alert may contain a prompt edit field.

3.1 Prompts

Prompts are basically requests for information. On most GUI platforms, prompts take the form of dialog boxes that request information from the user. The author answers the requests by setting modifying control values (i.e. typing text in a textbox or selecting a checkbox). Prompts are relatively unintrusive because they are often displayed at the user's request.  For example, when the user has chosen to save a document and the application prompts for the user to enter a name. However, once the author has dismissed a prompt, its message is unavailable unless the user requests it again.

For the purposes of the ATAG Guidelines Document, prompts can be used to encourage authors to provide information required for accessibility. For example, in the case of HTML, a prominently displayed alt-text entry field in an image insertion dialog, would constitute a prompt.

3.1.1 Field Priority:

In the ATAG document, the interface priority of controls related to accessibility is governed by 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 other editing tasks.  The checkpoint merely emphasizes that these controls should be allotted screen presence that is appropriate for their importance. In the example below, Allaire HomeSite prompts the user to enter alt-text by including this attribute value as the second text field within the dialog that is displayed during image insertion.

3.1.2 Highlighting:

Conformance with Checkpoint 5.2 may be reinforced by visually highlighting accessibility features with colour, icons, underlining, etc.  The following example, also from Allaire HomeSite, demonstrates how attention might be drawn more explicitly to an accessibility-related prompt field. In this case, the author did not add alt-text when they first inserted the image. As a result, the dialog contains symbols, colour changes and explanatory text that highlight the problem when the author opens the tag for editing later.

3.1.3 Related Prompts:

Sometimes a number of accessible editing tasks are required for a single element. 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, also from Allaire HomeSite, the multiple accessibility requirements of the HTML input form control (i.e. Access Key, Tab Index, Title and Label Text) are prompted for from within the same dialog.

4.1.4 Sequential Prompts:

In some cases, authors may benefit from the sequential presentation of a number of prompts. This technique usually takes the form of a wizard or a checker. In the case of a wizard, relatively complex interactions are broken down into a number of simple steps so that later steps can 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.

The first example, is a spelling and grammar checker from Microsoft Word 97. 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 a number of 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 (8 of 20) 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.

3.2 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.

3.2.1 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 insertion prompt.

When the author dismisses an intrusive alert, the program may or may not display a prompt allowing the author make the appropriate action.

IMPORTANT NOTE: While intrusive alerts are the least user-friendly form of prompting, there are situations in which the editing process is complete and publishing to the Web appears imminent. This may be the case when a document composed in a proprietary (non-Web format) is saved out into Web format.  In these cases, unintrusive alerts are not an option since there is simply no editing process left. An alternative to a number of alerts might be a number of sequential prompts (i.e. wizard) that could take the user through a process by which the inaccessible proprietary document is converted into an accessible Web document.

3.2.2 Unintrusive Alerts

Unintrusive alerts are interface objects such as icons, underlines, and gentle sounds that can be presented to the author without requiring immediate action. For example, in some word processors misspelled text is highlighted in the text, without forcing the author to make the correction immediately. 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.  As an example, Microsoft Word 97 includes the option to underline spelling errors in red and grammatical errors in green. When the user right-clicks on the highlighted text, they are presented with several correction options.

Another Microsoft product, FrontPage 3.0, uses unintrusive alerts in its HTML editing environment to indicate syntax errors.  As the author types, the syntax is automatically checked.  The author is allowed to make syntax errors, but the colour of the text signals that an error has been made.

In the context of the ATAG guidelines, such 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.