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)
Required by Relative Priority to WCAG 1.0:
Suggested:
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)
Required by Relative Priority to WCAG 1.0:
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)
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)
Required by Relative Priority to WCAG 1.0:
Required:
Suggested:
Reference:
3.2 Help the author create structured content and separate information from its presentation. [Relative Priority] (Checkpoint 3.2)
Required by Relative Priority to WCAG 1.0:
Required:
Suggested:
Reference:
Samples:
WCAG Checkpoint 2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. [Priority 1]
Techniques for WCAG checkpoint 2.1
General
 
WCAG Checkpoint 2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].
Techniques for WCAG checkpoint 2.2
General
  • Provide a monochrome preview for the author to test themselves.
WCAG Checkpoint 3.1 When an appropriate markup language exists, use markup rather than images to convey information. [Priority 2]
Refer also to WCAG guideline 6 and WCAG guideline 11.
Techniques for WCAG checkpoint 3.1
General
Refer also to checkpoint 2.1.
  • For mathematical content use MathML [MATHML], TeX or LaTeX.
  • For tabular data (for example timetables) use an HTML table, or XML.
  • In some cases it is helpful to include a graphic form as well as a markup-based form. For example, a graph may be presented along with the XML source data used to generate it. Or it may be an SVG image [SVG] which contains the source data within the SVG file, as RDF [[RDF]].
WCAG Checkpoint 3.3 Use style sheets to control layout and presentation. [Priority 2]
Techniques for WCAG checkpoint 3.3
Text / hypertext
  • Recognize formatting patterns and convert them to style rules.
  • Provide a view which allows the author to edit the layout and styling effects independently of the text content.
WCAG Checkpoint 3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
Techniques for WCAG checkpoint 3.5
Text / hypertext
  • Prompt the author to identify headings and subheadings
  • Provide an "outline" or "structure" view which allows the author to easily grasp the heading structure, and edit it.
WCAG Checkpoint 3.6 Mark up lists and list items properly. [Priority 2]
Techniques for WCAG checkpoint 3.6
text / hypertext
  • Include lists (marked as lists) in a collapsible structure view
WCAG Checkpoint 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation. [Priority 2]
Techniques for WCAG checkpoint 3.7
HTML
Automatically include (configurable or localized) quotation marks around quotations. This will encourage authors to use the markup, and not to misuse it.
Where material appears within quote marks ask the author if this is a quotation.
WCAG Checkpoint 4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). [Priority 1]
Techniques for WCAG checkpoint 4.1
Text / hypertext
  • Use a dictionary lookup to recognize words, and changes in the natural language used.
  • Provide an option in spellcheckers to identify a word or phrase that is not recognized as being in a natural language other than the primary language of the document.
WCAG Checkpoint 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs. [Priority 3]
Techniques for WCAG checkpoint 4.2
HTML
Ask the author to provide an expansion for abbr and acronym elements or confirm that a previously supplied one should be used again.
General
Provide a dictionary mechanism that recognizes abbreviations and prompts the author to include appropriate markup.
WCAG Checkpoint 4.3 Identify the primary natural language of a document. [Priority 3]
Techniques for WCAG checkpoint 4.3
General:
Ask the author to identify the language of any document. Provide a mechanism for setting a default.
WCAG Checkpoint 5.1 For data tables, identify row and column headers. [Priority 1]
Techniques for WCAG checkpoint 5.1
WCAG Checkpoint 5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1]
For example, in HTML, use THEAD, TFOOT, and TBODY to group rows, COL and COLGROUP to group columns, and the "axis", "scope", and "headers" attributes, to describe more complex relationships among data.
Techniques for WCAG checkpoint 5.2
HTML
Ask the author to group columns, rows, or blocks of cells that are related.
WCAG Checkpoint 5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2]
Refer also to WCAG checkpoint 3.3.
Techniques for WCAG checkpoint 5.3
HTML
  • Prompt the author to identify tables which are used as layout devices.
  • For layout tables, provide a linearized version, and offer it as a link from the table or as a replacement. An example tool which linearizes tables is tablin. It is also possible to provide a link direct to tablin [[TABLIN]].
WCAG Checkpoint 5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2]
Techniques for WCAG checkpoint 5.4
WCAG Checkpoint 5.5 Provide summaries for tables. [Priority 3]
Techniques for WCAG checkpoint 5.5
HTML
  • In a table creation wizard, include a summary or caption dialog
  • Render the caption, title and summary of a table, or prompt for content.
  • dialog image: screenshot Amaya's user interface guides the author to include a caption for tables, in the following way: When the author creates a table, a dialog is generated which asks for number of rows, columns, border width

    empty table inserted screenshot The author selects the appropriate information and a table is created. The cursor is placed at the position of the table caption. The status line, which appears at the bottom of the image, shows that the position is in the caption element of the table. (This is a standard part of the Amaya user interface).

WCAG Checkpoint 5.6 Provide abbreviations for header labels. [Priority 3]
Techniques for WCAG checkpoint 5.6
HTML
Prompt for an abbreviated form of each table header (th)
WCAG Checkpoint 6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. [Priority 1]
Techniques for WCAG checkpoint 6.1
HTML
Provide a "draft" view which does not apply styling.
WCAG Checkpoint 6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1]
Techniques for WCAG checkpoint 6.2
SVG
Prompt for appropriate changes to title and desc elements which are children of the target of an animate.
HTML
See also frames.
WCAG Checkpoint 6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]
Refer also to WCAG guideline 1.
Techniques for WCAG checkpoint 6.3
HTML
  • Prompt for server-side alternatives for scripts and applets
  • Prompt for noscript content for each script.
  • Prompt for alternative content for applets and programmatic objects (for example object elements which have a code attribute).
WCAG Checkpoint 6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2]
Refer to the definition of device independence.
Techniques for WCAG checkpoint 6.4
Applet development
  • Prompt the author to include device-independent means of activation
WCAG Checkpoint 6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2]
Techniques for WCAG checkpoint 6.5
HTML
Ask the author for:
  • appropriate links and content to include in a noframes element
  • a server-side alternative to applets and script functions
WCAG Checkpoint 7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker. [Priority 1]
Techniques for WCAG checkpoint 7.1
WCAG Checkpoint 7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). [Priority 2]
Techniques for WCAG checkpoint 7.2
WCAG Checkpoint 7.3 Until user agents allow users to freeze moving content, avoid movement in pages. [Priority 2]
Refer also to WCAG guideline 8.
Techniques for WCAG checkpoint 7.3
WCAG Checkpoint 7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects. [Priority 2]
Techniques for WCAG checkpoint 7.5
WCAG Checkpoint 8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]
Refer also to WCAG guideline 6.
Techniques for WCAG checkpoint 8.1
WCAG Checkpoint 9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape. [Priority 1]
Refer also to WCAG checkpoint 1.1, WCAG checkpoint 1.2, and WCAG checkpoint 1.5.
Techniques for WCAG checkpoint 9.1
HTML
where regions are not easily defined, ask the author to provide information that can be used to generate a form-based input method and explains how the coordinates input will be used. For example, on a map the input might be used to lookup latitude and longitude of a point and then give information about that point.
WCAG Checkpoint 9.2 Ensure that any element that has its own interface can be operated in a device-independent manner. [Priority 2]
Refer also to WCAG guideline 8.
Techniques for WCAG checkpoint 9.2
WCAG Checkpoint 9.3 For scripts, specify logical event handlers rather than device-dependent event handlers. [Priority 2]
Techniques for WCAG checkpoint 9.3
WCAG Checkpoint 9.4 Create a logical tab order through links, form controls, and objects. [Priority 3]
Techniques for WCAG checkpoint 9.4
HTML
Where there are only a few links that change in each page of a collection, ask the author if they should receive focus first. If so, then give them a tabindex, leaving the rest to after the tabindexed links have been focused.
WCAG Checkpoint 9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls. [Priority 3]
Techniques for WCAG checkpoint 9.5
HTML
Ask authors to specify an accesskey for links that appear common to a number of pages
WCAG Checkpoint 10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. [Priority 2]
Techniques for WCAG checkpoint 10.1
HTML
Where a link or active element will spawn a new window, prompt the author for title text to make this clear.
WCAG Checkpoint 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. [Priority 2]
Refer also to WCAG checkpoint 12.4.
Techniques for WCAG checkpoint 10.2
WCAG Checkpoint 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. [Priority 3]
Techniques for WCAG checkpoint 10.4
HTML
Prompt the author for default place-holder text. Offer the value of the name attribute as a default.
WCAG Checkpoint 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links. [Priority 3]
Techniques for WCAG checkpoint 10.5
WCAG Checkpoint 11.2 Avoid deprecated features of W3C technologies. [Priority 2]
Techniques for WCAG checkpoint 11.2
WCAG Checkpoint 11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.) [Priority 3]
Note. Use content negotiation where possible.
Techniques for WCAG checkpoint 11.3
WCAG Checkpoint 11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. [Priority 1]
Techniques for WCAG checkpoint 11.4
WCAG Checkpoint 12.1 Title each frame to facilitate frame identification and navigation. [Priority 1]
Techniques for WCAG checkpoint 12.1
HTML
  • Prompt the author for a short, human-readable title for each frame. Default text presented in the prompt could use the title defined for the document referenced in the src
WCAG Checkpoint 12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2]
Techniques for WCAG checkpoint 12.2
HTML
  • Prompt the author for a longdesc for each frame in a frameset.
  • Prompt the author to add a noframes section to the frameset. Encourage the author to include sufficient links to navigate the site, and relevant information. For example, where a frameset defines a navigation frame and a welcome page, include the content of each of these frames in the noframes.
WCAG Checkpoint 12.3 Divide large blocks of information into more manageable groups where natural and appropriate. [Priority 2]
Refer also to WCAG guideline 3.
Techniques for WCAG checkpoint 12.3
HTML
Where there are more than 10 choices in a list (select, checkbox or radio boxes) ask the author to identify subgroups
WCAG Checkpoint 12.4 Associate labels explicitly with their controls. [Priority 2]
Techniques for WCAG checkpoint 12.4
HTML
Ask authors to mark explicitly the labels for form inputs (input and textarea elements)
WCAG Checkpoint 13.1 Clearly identify the target of each link. [Priority 2]
Techniques for WCAG checkpoint 13.1
General
Prompt the author to provide text which can be used as a title for a link.
WCAG Checkpoint 13.2 Provide metadata to add semantic information to pages and sites. [Priority 2]
Refer also to WCAG checkpoint 13.5.
Techniques for WCAG checkpoint 13.2
General
Ask authors for information about a page or site. If its function is known (see also WCAG checkpoint 13.9) add this information as metadata.
WCAG Checkpoint 13.3 Provide information about the general layout of a site (e.g., a site map or table of contents). [Priority 2]
Techniques for WCAG checkpoint 13.3
General
Prompt the author to provide a link or content describing the structure of the site, and its accessibility features.
WCAG Checkpoint 13.4 Use navigation mechanisms in a consistent manner. [Priority 2]
Techniques for WCAG checkpoint 13.4
WCAG Checkpoint 13.5 Provide navigation bars to highlight and give access to the navigation mechanism. [Priority 3]
Techniques for WCAG checkpoint 13.5
WCAG Checkpoint 13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. [Priority 3]
Techniques for WCAG checkpoint 13.6
HTML
Ask authors if lists of links are a group and should be a map.
WCAG Checkpoint 13.9 Provide information about document collections (i.e., documents comprising multiple pages.). [Priority 3]
Techniques for WCAG checkpoint 13.9
General
  • Pattern-matching - ask authors to specify the role of pages linked from a navigation bar.
  • Where common names are used (search, home, map) as links, ask the author to confirm these functions for use in linking.
WCAG Checkpoint 13.10 Provide a means to skip over multi-line ASCII art. [Priority 3]
Refer to WCAG checkpoint 1.1 and the example of ascii art in the glossary.
Techniques for WCAG checkpoint 13.10
HTML
Where a PRE element is used with substantial punctuation and non-words, ask for text alternative.
WCAG Checkpoint 14.1 Use the clearest and simplest language appropriate for a site's content. [Priority 1]
Techniques for WCAG checkpoint 14.1
General
  • Provide readability ratings for text.
  • Provide a thesaurus function
  • Provide a grammar-checking function
WCAG Checkpoint 14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page. [Priority 3]
Refer also to WCAG guideline 1.
Techniques for WCAG checkpoint 14.2
3.3 Ensure that prepackaged content conforms to the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Relative Priority] (Checkpoint 3.3)
For example, include captions, an auditory description, and a collated text transcript with prepackaged movies. Refer also to checkpoint 3.4.
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)
For example, prompt the author for a text equivalent of an image. If the author has already provided a text equivalent for the same image used in another document, offer to reuse that text and prompt the author for confirmation. If the tool automatically generates a "Search" icon, it would be appropriate to automatically reuse the previously authored text equivalent for that icon. Refer also to checkpoint 3.3 and checkpoint 3.5.

Note: Human-authored equivalent alternatives may be available for an object (for example, through checkpoint 3.5 and/or checkpoint 3.3). It is appropriate for the tool to offer these to the author as defaults.

3.5 Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects. [Priority 3] (Checkpoint 3.5)
Note: These alternative equivalents may be packaged with the tool, written by the author, retrieved from the Web, etc.

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

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.
4.2 Assist authors in correcting accessibility problems. [Relative Priority] (Checkpoint 4.2)
At a minimum, provide context-sensitive help with the accessibility checking required by checkpoint 4.1
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.
4.4 Provide the author with a summary of the document's accessibility status. [Priority 3] (Checkpoint 4.4)
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)

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

Checkpoints:

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

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:
Samples:
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)
 

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

Checkpoints:

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)
 
The techniques for this checkpoint include references to checklists and guidelines for a number of platforms and to general guidelines for accessible applications.
Requirements:

The following are common requirements for producing accessible software. This list does not necessarily cover all requirements for all platforms, and items may not apply to some software.

Following Standards

Configurability

Input Device Independence

Icons, Graphics, Sounds

Layout

User Focus

Documentation

References:
7.2 Allow the author to change the presentation within editing views without affecting the document markup. [Priority 1] (Checkpoint 7.2)
Requirements:
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:
Sample:
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:
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.