dFigure A-1: Accessibility options card.
(Source: contrived???)
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 will be included. These are purely illustrative and, although, in some cases these mockups have been contrived from interface elements in existing applications, they are not intended to express any opinion of the AUWG or its members regarding the applications in question.
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."
isn't this a bit narrow - esp as we are now thinking about prompting in live-authoring situations - so it might be voice that is being modified...etc..
In other words, "prompting" is used to denote any user interface mechanism that provides the author with the opportunity to add accessible content 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 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.
d
Figure A-1: Accessibility options card.
(Source: contrived???)
It is preferable to guide the user towards the production of accessible content, rather than to allow the author free rein, only to have to inform them of the full weight of the accumulated problems, 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.
Should the comma be where it is?
There are several ways this type of prompting might be achieved:
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.
is that comma correct? isn't it better to have 'properties' for consistency?
d
Figure A-2: Floating properties bar (top: maximized, bottom:
minimized) with prominent alt field.
(Source: Macromedia Dreamweaver 2.0)
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, however, 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 a black dot icon to denote the required field insert a comma here?? delete the word icon?? 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).
delete 'however'???
d
Figure A-3: Input field highlighting with an
iconic reference
to a note.
(Source: contrived)
d
Figure A-4: Input field highlighting with colored
input field.
(Source: contrived)
In some cases, several input fields are required to be completed in order 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 with a visible tab or other method for accessing the group (see Figure A-5). This can have the additional benefit of allowing accessibility-related help information to be provided without confusion (see "Quick Tips" in the figure, below). The downside of placing all the accessibility related input fields in the same area is that all of them will be neglected if the author does not see the grouping--- regocnise they are grouped???.
d
Figure A-5: Accessibility tab on the
input element
properties dialog.
(Source: contrived from HomeSite)
It may be a convention to use the word contrived but it does not work for me with my English ... constructed makes more sense...eg
Prompting, of the kind envisioned, is required to anticipate and prevent problems with accessibility. If (delete Once??) accessibility problems are present (created??)? in a document, the author may not visit the offending content and so may not see the properties dialogs and other insertion mechanisms may not be seen by the author again (delete?) , substantially reducing the effectiveness of the any (delete???) 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 a (delete???) prompting mechanisms that can operate more generally. Since the problems are already present in the markup, such a system (this???) 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:
An immediate interruption is the most intrusive form of prompting. Within it (delete and just have a colon?? ), the author's attention is intentionally (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 (such??) alerts present multiple usability problems, and should be used sparingly because they interfere 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 corrections (delete the s???) 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.
d
Figure A-6: Accessibility alert dialog.
(Source: contrived)
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 right-clicks (wow!! delete right?? ) on the highlighted text, they could be presented with several correction options. Besides being unintrusive, these types of (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 recommended (recommends??) that, at some major editing event (e.g., publish (when publishing?) ), the tool should?? remind the author of the existing (continuing??) unresolved accessibility issues.
d
Figure A-7: Object highlighting of an accessibility problem
in a WYSIWYG editor.
(Source: contrived)
d
Figure A-8: Font highlighting of an accessibility problem in
a text view.
(Source: contrived)
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.
d
Figure A-9: A scheduled prompt as part of a
"save as"
dialog.
(Source: contrived)
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 solely (delete???) on the issue at hand (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 (plus???) additional information and tips that the author may require in order to properly provide the requested information (see Figure A-10). Notice that (in Fig 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 that had been (delete??) used previously for the alt-text of this image (see ATAG Checkpoint 3.5 for more).
d
Figure A-10: Accessibility problem checker.
(Source: contrived from A-Prompt).
In cases where there are many pieces of information required (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 correction (delete??) word. The user also has several (delete???) correcting options, some of which can store responses to affect how the same situation is handled later.
Also?? In an accessibility problem checker, sequential prompting is also (delete??) 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 the (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.
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 also (delete???) 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:
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:
McFarlane, Daniel C. (1999) "Coordinating the Interruption of People in Human-Computer Interaction", Human-Computer Interaction - INTERACT '99, pp. 295-303.
Last updated by: Jan Richards, 16 April 2002.