[] [contents of this page] [full techniques contents]


Techniques for Authoring Tool Accessibility Guidelines 1.0

Working Draft 8 March 2002

Appendix A: Techniques for User Prompting

This version:
Latest version:
Previous version:


editor of this chapter:

Jan Richards

Appendix A: Techniques for User Prompting

Table of Contents

Instances of the term "prompting" in ATAG 1.0

The term "prompting" appears in the following locations in the Authoring Tool Accessibility Guidelines.

What does "prompting" mean?

The ATAG 1.0 glossary defines "prompting" as follows:

A "prompt" is a request for author input, either information or a decision. For example, a text equivalent entry field prominently displayed in an image insertion dialog would constitute a prompt. In this document prompt does not refer to the narrow software sense of a "prompt," rather it is used as a verb meaning to urge, suggest and encourage. The form and timing that this prompting takes can be user configurable. "Prompting" does not depend upon the author to seek out the support but is initiated by the tool. "Prompting" is more than checking, correcting, and providing help and documentation as encompassed in guidelines 4, 5, 6. The goal of prompting the author is to encourage, urge and support the author in creating meaningful equivalent text without causing frustration that may cause the author to turn off access options. Prompting should be implemented in such a way that it causes a positive disposition and awareness on the part of the author toward accessible authoring practices.

In other words, in the ATAG 1.0 guidelines, the term "prompting" is used 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 on a user configurable schedule

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

Screenshot of Word2000 spelling options include checking as you type, suggestions, and what to ignoreD
Figure A-1: Options card (source: MS Word 2000).

Types of Prompting

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

Priority of Prompt Fields:

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

Screenshot of Dream Weaver property dialog for image including alt-text field D
Figure A-2: Floating properties bar with prominent alt field (source: Macromedia DreamWeaver 2.0)

Prompt Highlighting:

Conformance with checkpoint 5.2 may be reinforced by visually highlighting accessibility features with color, 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, color 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.

Screenshot of Homesite image tag editor includes red asterix to explanatory note beside alt-text fieldD
Figure A-3: Reference to explanatory note (source: Allaire HomeSite)

Grouping Related Prompts:

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.

Screenshot of HomeSite tag editor for input element D
Figure A-4: Tag editor for the input element with an accessibility tab (source: Allaire HomeSite)

Sequential Prompts:

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.

Screenshot of Word2000 spelling and grammar checkerD
Figure A-5: Spelling and grammar checker (source: MS Word 2000).

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

Screenshot of the A-prompt missing alt text dialogD
Figure A-6: An alternate text writing utility (source: contrived from A-Prompt).


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

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.

Screenshot of dialog saying you must enter text to describe this image D
Figure A-7: Intrusive alert

Warning-at-save.gif (7085 bytes)D
Figure A-8: A saving dialog showing an unintrusive alert during a save (source: contrived from Macromedia DreamWeaver 2.0)

Unintrusive Alerts

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.

Screenshot of Word2000 showing the red and green underlines for spelling and grammar errors D
Figure A-9: An inline spelling and grammar error highlighting facility (source: MS Word 2000)

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 color of the text signals that one or more errors have been made.

Screenshot of Frontpage2000 showing the red font used to indicate syntax errorsD
Figure A-10: The FrontPage 2000 HTML view shows syntax errors with a red font.

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.

[previous section] [top of this page] [full techniques contents]