NOTES ABOUT THIS DRAFT:

  1. Intro, references, etc. have been removed fro 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 techs - 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

The ATAG guidelines often refer to the practice of prompting. The importance of these concepts in the document and a perceived ambiguity of their meanings has been identified as a source of confusion. These techniques will attempt to clarify the issue. Although the following guidelines and checkpoints make explicit use of them, others may refer to prompting implicitly :

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. The following are responses to concerns raised by developers.

Important: 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])

Prompting on a user configurable schedule

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.

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

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 property card. View screenshot.

3.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.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 Guidelines, 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.

Field Priority:

In the Guidelines, 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 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 cases such as the image element, the author can toggle the toolbar between a limited and extended set of properties. Importantly, in terms of checkpoint 5.2, the alt attribute property is afforded sufficient field priority to appear on the limited version of the toolbar.

Screenshot of Dream Weaver property dialog for image including alt-text field D

Screenshot of Dream Weaver property dialog for image including alt-text field.

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 an accessibility-related prompt fields. In this case, the Homesite tag editor dialog contains symbols, colour changes and explanatory text highlight alt-text as 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

Screenshot of Homesite image tag editor includes red asterix to explanatory note beside alt-text field

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.

Screenshot of HomeSite tag editor for input element D

Screenshot of HomeSite tag editor for input element.

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 2000. 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 spelling 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.

Screenshot of Word2000 spelling and grammar checkerD

Screenshot of Word2000 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 (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.

Screenshot of the A-prompt missing alt text dialogD

Screenshot of the A-prompt missing alt text dialog.

3.4 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. 5 Integrate accessibility solutions into the overall "look and feel". .

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.

Screenshot of dialog saying you must enter text to describe this image D

Screenshot of dialog saying you must enter text to describe this image.

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

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.

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 2000 includes the option to underline spelling errors in red and grammatical errors in green. (Note that a user must be able to change this default presentation - users who are red-green colorblind, for example, will not be able to perceive the information being conveyed by this default). 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

Screenshot of Word2000 showing the red and green underlines for spelling and grammar 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. The author is allowed to make syntax errors, but the colour of the text signals that an error has been made.

Screenshot of Frontpage2000 showing the red font used to indicate syntax errorsD

Screenshot of Frontpage2000 showing the red font used to indicate syntax errors.

In the context of the Authoring Tool 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.

Example Screenshots:

Screenshot of Word2000 spelling options include checking as you type, suggestions, and what to ignoreD

Figure 1: Screenshot of Word2000 spelling options include checking as you type, suggestions, and what to ignore.