NOTES ABOUT THIS DRAFT:

  1. Intro, references, etc. have been removed for clarity. They will of course be replaced for publishing.
  2. In the introduction we emphasize the new techniques structures: i.e. the break-out documents for each language, the required/suggested breakdown, the concept of Crossover's (practices that go towards satisfying multiple checkpoints), references, and screenshot samples.
  3. Perhaps we can produce a top-10 access upgrade suggestions (including reference to checkpoints that will be satisfied).
  4. I see a tighter relationship between the guidelines and the techniques - so no need to repeat ourselves (guideline intros , etc.)

2 Techniques by ATAG Guideline

Guideline 1. Support accessible authoring practices.

ATAG 1.1 Ensure that the author can produce accessible content in the markup language(s) supported by the tool. [Priority 1] (Checkpoint 1.1)
Required:
Suggested:
Reference:
ATAG 1.2 Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions. [Priority 1] (Checkpoint 1.2)
Required:
Suggested:
Reference:
ATAG 1.3 Ensure that when the tool automatically generates markup it conforms to the W3C's Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Checkpoint 1.3)
Relative Priority to WCAG 1.0:
* REMEMBER: The equivalent alternatives themselves may not be automatically generated unless the function of the non-text element is known with certainty (see ATAG 3.4). If the function of the non-text element is not known with certainty, then author input will be required, at some point, to approve or create a new equivalent alternative.
Reference:
ATAG 1.4 Ensure that templates provided by the tool conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Checkpoint 1.4)
Relative Priority to WCAG 1.0:
* REMEMBER: The equivalent alternatives themselves must not be automatically generated unless the function of the non-text element was known with certainty (ATAG 3.4). If the function of the non-text element was not known with certainty, then the equivalent alternative must be created "by hand" by the template developer.
Suggested:
Reference:
Samples:

Guideline 2. Generate standard markup.

2.1 Use the latest versions of W3C Recommendations when they are available and appropriate for a task. [Priority 2] (Checkpoint 2.1)
Required:
Suggested:
Reference:
2.2 Ensure that the tool automatically generates valid markup. [Priority 1] (Checkpoint 2.2)
Required:
Reference:
2.3 If markup produced by the tool does not conform to W3C specifications, inform the author. [Priority 3] (Checkpoint 2.3)
Required:
Suggested:
Samples:

Guideline 3. Support the creation of accessible content.

ATAG 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.1)
Relative Priority to WCAG 1.0:
Suggested:
Reference:
ATAG 3.2 Help the author create structured content and separate information from its presentation. [Relative Priority] (Checkpoint 3.2)
Relative Priority to WCAG 1.0:
Reference:
Samples:
ATAG 3.3 Ensure that prepackaged content conforms to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Checkpoint 3.3)
Required:
Suggested:
Sample
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] (Checkpoint 3.4)
Required:
Suggested:
3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3] (Checkpoint 3.5)
 
Note: This checkpoint is priority 3, so it does not have a critical effect on an authoring tool's likelihood of producing accessible mark-up. However, implementing this checkpoint has the potential to simultaneously satisfy several higher priority checkpoints (ATAG 3.1, ATAG 3.2, and ATAG 3.4) and dramatically improve the usability of an authoring tool.
Suggested:
References:

Guideline 4. Provide ways of checking and correcting inaccessible content.

Checkpoints:

4.1 Check for and inform the author of accessibility problems. [Relative Priority] (Checkpoint 4.1)
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. In the section below, the evaluation (ATAG 4.1) and repair (ATAG 4.2) techniques for each WCAG checkpoint have been grouped together.
Relative Priority to WCAG 1.0:
Suggested:
Reference:
Samples:
4.2 Assist authors in correcting accessibility problems. [Relative Priority] (Checkpoint 4.2)
Suggested:
Samples:
4.3 Allow the author to preserve markup not recognized by the tool. [Priority 2] (Checkpoint 4.3)
Note: The author may have included or imported markup that enhances accessibility but is not recognized by the tool.
Required:
Suggested:
4.4 Provide the author with a summary of the document's accessibility status. [Priority 3] (Checkpoint 4.4)
Required:
Suggested:
Samples:
4.5 Allow the author to transform presentation markup that is misused to convey structure into structural markup, and to transform presentation markup used for style into style sheets. [Priority 3] (Checkpoint 4.5)
Required:
Suggested:
Samples:

Further techniques for this guideline are given in the appendix Techniques for User Prompting

Guideline 5. Integrate accessibility solutions into the overall "look and feel".

ATAG 5.1 Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the tool. [Priority 2] (Checkpoint 5.1)
Required:
Suggested:
Samples:
ATAG 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] (Checkpoint 5.2)
Required:
Suggested:
Sample:

Guideline 6. Promote accessibility in help and documentation.

Checkpoints:

ATAG 6.1 Document all features that promote the production of accessible content. [Priority 1] (Checkpoint 6.1)
Required:
Suggested:
ATAG 6.2 Ensure that creating accessible content is a naturally integrated part of the documentation, including examples. [Priority 2] (Checkpoint 6.2)
Required:
Suggested:
ATAG 6.3 In a dedicated section, document all features of the tool that promote the production of accessible content. [Priority 3] (Checkpoint 6.3)
Required:
Suggested:

Guideline 7. Ensure that the authoring tool is accessible to authors with disabilities.

Checkpoints:

ATAG 7.1 Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions that are essential to accessibility; Priority 2 for those that are important to accessibility; Priority 3 for those that are beneficial to accessibility). (Checkpoint 7.1)
Requirements:
The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications. This list does not cover all requirements for all platforms, and items may not apply to some software. In addition, not all of the guidelines and checklists for application accessibility are prioritized according to their impact on accessibility. For instance, the priorities in "The Microsoft Windows Guidelines for Accessible Software Design" [MS-SOFTWARE] are partially determined by a logo requirement program. Therefore, developers may need to compare the documents they are using to other UAAG 1.0 [UAAG10] that has a priority system that is directly compatible with the priorities in [ATAG10]. Also, when user interfaces are built as Web content, they should follow the Web Content Accessibility Guidelines 1.0 [WCAG10].
References:
ATAG 7.2 Allow the author to change the presentation within editing views without affecting the document markup. [Priority 1] (Checkpoint 7.2)
Requirements:
Suggested:
Samples:
ATAG 7.3 Allow the author to edit all properties of each element and object in an accessible fashion. [Priority 1] (Checkpoint 7.3)
Required:
Suggested:
Samples:
ATAG 7.4 Ensure that the editing view allows navigation via the structure of the document in an accessible fashion. [Priority 1] (Checkpoint 7.4)
Required:
Suggested:
Sample:
ATAG 7.5 Enable editing of the structure of the document in an accessible fashion. [Priority 2] (Checkpoint 7.5)
Suggested:
7.6 Allow the author to search within editing views. [Priority 2] (Checkpoint 7.6)
Required:
Suggested:
Samples:

Appendix A: Techniques for User Prompting

Instances of the term "prompting"

The ATAG guidelines sometimes refer to the practice of prompting. The importance of this concept in the document and a perceived ambiguity of its meaning has been identified as a source of confusion. These techniques will attempt to clarify the issue. Remember that although the following guidelines and checkpoints make explicit use of the term, other guidelines may be best implemented using some form of prompting as well.

What does "prompting" mean?

The term "prompting" is used in the document 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: MS Word 2000 spelling and grammar options.

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:

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: The Macromedia DreamWeaver 2 image properties dialog always includes the alt-text field.

Prompt Highlighting:

Conformance with checkpoint 5.2 may be reinforced by visually highlighting accessibility features with colour, 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, colour 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: The HomeSite image tag editor includes a reference to an explanatory note
beside the alt-text field

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: The HomeSite tag editor for the INPUT element includes an accessibility tab.

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: Word2000 includes a spelling and grammar checker.

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 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: The A-Prompt missing alt-text correction dialog includes an image viewer, guidelines and
previously authored text defaults (if available).

Alerts:

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: A contrived dialog alert.

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

Warning-at-save.gif (7085 bytes)D
Figure A-8: A contrived dialog shows an unintrusive alert during a save.

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: Word2000 includes a facility for showing red and green underlines beneath spelling and grammatical errors.

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 colour 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 Frontpage2000 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.