Contents | Tier 1 | Tier 2 | Tier 3 | Tier 4 | Appendix A: Prompting | Glossary | References

Implementation Techniques for
Authoring Tool Accessibility Guidelines Wombat:

Appendix A: Techniques for user prompting

Group Working Draft 11 September 2002

This version:
h ttp://www.w3.org/WAI/AU/2002/WD-ATAG-WOMBAT-TECHS-20020911/appa
Latest version:
http://www.w3.org/TR/A TAG-wombat-techs/appa
Previous version:
h ttp://www.w3.org/WAI/AU/2002/WD-ATAG-WOMBAT-TECHS-20020820/appa
ATAG 1.0 Recommendation:
http://www.w3.org/TR/ATAG10
Editors of this chapter:

Jan Richards

Copyright 1999 - 2002 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


Table of Contents


Purpose

The purpose of this appendix is to more fully explain the sense in which "prompting" is used in ATAG v1.0. This document will try to situate the concept of prompting in the scope of classical HCI paradigms, where it is linked to the psychological concept of user-interruption (McFarlane, 1999). Four user-interruption methods are usually identified: (1) immediate, (2) negotiated, (3) mediated, and (4) scheduled. In the case of web authoring, the third case, mediated, is not relevant. Several interface mockups are included for illustrative reasons. They are not intended as expressions of any AUWG or member opinion.


The ATAG Definition of "Prompting"

The concept of "prompting" is central to the practical implementation of the ATAG guidelines v1.0. The term appears several times in the guidelines themselves and dozens of times in the ATAG implementation techniques. Including:

When ATAG 1.0 was first released there were some misunderstandings about whether the original definition of "prompting" implied that less intrusive mechanisms such as prominent input fields and in-line prompting would not qualify. In fact, the AUWG believes they should, so on 5 July 2000, an Errata was published that clarified the definition:

"In this document [ATAG v1.0] '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 [ATAG v1.0] 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, "prompting" is used to denote any user interface mechanism that provides the author with the opportunity to add accessible content (Note: although the definition uses the phrase "equivalent text", this covers audio descriptions of video, etc.) or reminds them of the need to do so. The definition does not assume any particular prompting mechanism or require that the chosen mechanism be either irritating or aesthetically unpleasant. In fact, ATAG checkpoint 5.1 requires quite the opposite; that prompting be naturally integrated into the overall look and feel of the tool.

Remember: The ultimate goal of the "prompting" is to obtain correct and complete information with the assistance of the author . This is most likely to occur if the author has been convinced to provide the information voluntarily.


User Configurability

User acceptance of the accessibility features of an authoring tool will most likely depend on the degree to which the new features preserve existing author work patterns. That is why the ATAG definition clearly states that: "the form and timing that this prompting takes can be user configurable". In other words, the author should be able to control how and when prompting will appear in order to reconcile the additional accessibility authoring tasks with their regular work patterns. To achieve this, tools may offer the author a range of checking and prompting options (see Figure A-1). These might include allowing the author to specify:

Of course, as with all the examples in this document, this is just a suggestion. The Authoring Tools Working Group (AUWG) encourages developers to adapt and develop solutions that are suitable for their own tools.

Screenshot of contrived accessibility options dialogd
Figure A-1: Accessibility options card.
(Source: mockup by Jan Richards)


Prompting Before a Problem Exists

It is preferable to guide the user towards the production of accessible content. Otherwise, if the author is allowed free rein, they may be overwhelmed by the full weight of the accumulated problems once they are informed of them later in the authoring process. ATAG checkpoint 5.2 addresses this issue by recommending that input fields related to accessibility (as determined by WCAG) should be among the most obvious and easily initiated by the author. To a large extent, this means designing dialogs and other mechanisms so that the author's attention is drawn to the presence and purpose of accessibility-related input fields.

There are several ways this type of prompting might be achieved:

Input Field Order:

ATAG Checkpoint 5.2 does not require that accessibility related controls either obscure or hinder other controls. Instead, the checkpoint emphasizes that these controls should be allotted a screen presence that is appropriate for their importance. For example, some tools have floating properties bars that display input fields appropriate to the currently selected element (see Figure A-2). The relative importance of a property can be communicated to the author in two ways.

Screenshot of maximized and minimized Dreamweaver property dialog for image - including alt-text field d
Figure A-2: Floating properties bar (top: maximized, bottom: minimized) with prominent alt field.
(Source: Macromedia Dreamweaver 2.0)

Input Field Highlighting:

Visibility of input fields related to accessibility may be further enhanced by visual highlighting. For example, the fields may be distinguished from others using icons (see Figure A-3), color (see Figure A-4), underlining, etc. When these methods are used, it is important to ensure that that they are consistent with the overall look and feel of the authoring tool interface (as per ATAG Checkpoint 5.1). For example, if an authoring tool uses an icon in the shape of a black dot to denote the required field, this convention might be extended so that a red dot is used to denote the accessibility-related fields. An additional consideration is that in order to meet ATAG Checkpoint 7.1, the highlighting must be implemented so that it is available through APIs, allowing an author with disabilities to access the highlighting through assistive devices (MSAA, Java Accessibility API, GNOME accessibility).

Screenshot showing icon input field highlightingd
Figure A-3: Input field highlighting with an iconic reference to a note.
(Source: mockup by Jan Richards)

 Screenshot of showing colored input field highlighting d
Figure A-4: Input field highlighting with colored input field.
(Source: mockup by Jan Richards)


Prompting After a Problem Exists

If, despite the prompting discussed in the previous section, accessibility problems are created (or are present when a user opens a document for editing), the properties dialogs or other insertion mechanisms may not be seen by the author again, substantially reducing the effectiveness of any prompting that they contain. In addition, some accessibility problems arise from the interaction between multiple elements and are therefore not well suited to prompting in any particular insertion mechanism. Therefore, it is necessary to implement prompting mechanisms that can operate more generally. Since the problems are already present in the markup, this system will require a robust automated accessibility checking system (see ATAG checkpoint 4.1) in order to detect the problems and alert the author to them..

There are several ways this type of prompting might be achieved:

Immediate Prompting (Interruption)

An immediate interruption is the most intrusive form of prompting because the author's attention is actively diverted from the current editing task to highlight some accessibility issue (for instance, by an alert dialog, see Figure A-6). This type of alert presents multiple usability problems, and should be used sparingly because it interferes with the normal design process. Intrusive warnings are probably only appropriate when the window of opportunity for correcting a serious accessibility problem is about to close. An example of a closing window of opportunity for correction is when the author is publishing a document to their site. In general, we recommend using the less disruptive options that will be described in the following sections.

Screenshot of accessibility alert dialogd
Figure A-6: Accessibility alert dialog.
(Source: mockup by Jan Richards)

Negotiated Prompting (Interruption)

The term "negotiated interruption" refers to 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. This type of unintrusive alert can be better integrated into the design workflow.

For example, a colored outline might be drawn around an object in a WYSIWYG view (see Figure A-7) that has unresolved accessibility issues, while the markup text for the same object might by highlighted by a different font color in the code view (see Figure A-8). In either case, when the author clicks on the highlighted text, they could be presented with several correction options. 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 that the tool force 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.

Screenshot of WYSIWYG view with outline highlighting and pop-up men of correction optionsd
Figure A-7: Object highlighting of an accessibility problem in a WYSIWYG editor.
(Source: mockup by Jan Richards)

Screenshot of code view with font color accessibility highlightingd
Figure A-8: Font highlighting of an accessibility problem in a text view.
(Source: mockup by Jan Richards)

Scheduled Prompting (Interruption)

With scheduled prompting, the author can set the tool to alert them of accessibility issues on a configurable schedule (see Figure A-1). One option for the schedule might be to have the prompts associated with the interface mechanisms for significant authoring events (saving, exiting, publishing, printing, etc.). In this case, at the significant authoring event, the author is informed of the problem and is given the means to initiate the correcting actions (Note: The author should never be prevented from performing the significant authoring action, itself). For example, a "save as" dialog could display an accessibility warning and an option to launch a correction utility after saving (see Figure A-9). 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.

Screenshot of save as dialog with warning messaged
Figure A-9: A scheduled prompt as part of a "save as" dialog.
(Source: mockup by Jan Richards)

Correction:

Once the author has been made aware of a problem and chosen to correct it, the tool has at least two options. First, it might display the property editing mechanism for the offending element (see Figure A-2). This is the simplest solution, but it suffers from the drawback that it does not focus the author's attention on the required correction. The second option is to display a custom "correction" prompt that includes only the input field(s) for the information required as well as additional information and tips that the author may require in order to properly provide the requested information (see Figure A-10). Notice that in Figure A-10, 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).

Screenshot of contrived accessibility prompting checkerd
Figure A-10: Accessibility problem checker.
(Source: mockup by Jan Richards based on A-Prompt).

Sequential Prompting:

In cases where there are many pieces of information missing, authors may benefit from a sequential presentation of correction prompts. This may take the form of a wizard or a checker. 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.

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.


Prompting in a Real-Time (Live) Authoring Environment

When authoring tools produce real-time content, 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 should still take accessibility issues into account by supporting the following:

Screenshot of contrived whiteboard/chat tool with whiteboard description promptingd
Figure A-11: 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. (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:


References

McFarlane, Daniel C. (1999) "Coordinating the Interruption of People in Human-Computer Interaction", Human-Computer Interaction - INTERACT '99, pp. 295-303.


Contents | Tier 1 | Tier 2 | Tier 3 | Tier 4 | Appendix A: Prompting | Glossary | References