Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References

W3C

Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0

Guideline 3: Support the production of accessible content.

Working Group Draft 25 June 2004

This version:
http://www.w3.org/WAI/AU/2004/WD-ATAG20-20040625/tech3
Latest version:
http://www.w3.org/TR/ATAG20/tech3
ATAG 1.0 Recommendation:
http://www.w3.org/TR/ATAG10
Editors of this chapter:
Jutta Treviranus - ATRC, University of Toronto
Jan Richards - ATRC, University of Toronto
Matt May - W3C

Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Introduction to Guideline 3:

Actions may be taken at the author's initiative that may result in accessibility problems. The authoring tool should include features that provide support and guidance to the author in these situations, so that accessible authoring practices can be followed and accessible web content can be produced.

This support includes prompting and assisting the author to create accessible web content (Checkpoint 3.1), especially for information that cannot be generated automatically, checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3). In performing these functions, the authoring tool must avoid including automatically generated equivalent alternatives or previously authored equivalent alternatives without author consent (Checkpoint 3.4). The authoring tool may also provide automated means for managing equivalent alternatives (Checkpoint 3.5) and provide accessibility status summaries (Checkpoint 3.6).

Accessibility-related documentation provides support and guidance to the author. The documentation must accommodate the various levels of author familiarity with web content accessibility issues. The checkpoint requirements include documenting accessible content promoting features (Checkpoint 3.7), and ensuring that documentation demonstrates authoring practices and workflow processes that result in accessible content (Checkpoint 3.8).

Checkpoints in Guideline 3:

Notes:

  1. These techniques are informative. There are no claims made, implicit or explicit, that by following any of the techniques in this document any conformance requirements of the ATAG2.0 WD will be satisfied. Rather, these techniques represent an illustrative sampling of approaches that might be useful in considering the subject of authoring tool accessibility. There may be many other ways a tool might be designed and still meet the normative criteria contained in the success criteria.
  2. The techniques all use the phrasing "can", rather than "must" or "should". This is intended to reinforce to the reader the non-normative status of this document. It should be noted that some techniques are so important to meeting their respective success criteria, that for all practical purposes, the techniques are required. These techniques have been marked with the term "STRONGLY SUGGESTED".

@@BF: prompting for accessibility localization@@

@@we must ensure accessibility of examples (i.e that they meet GL1)@@

@@more help designing well - e.g. alternatives to image maps@@

ATAG Checkpoint 3.1: Prompt and assist the author to create accessible content. [Relative Priority]

Rationale: Appropriate assistance should increase the likelihood that typical authors will create WCAG-conformant content. Different tool developers will accomplish this goal in ways that are appropriate to their products, processes and authors.

Executive Summary of Techniques:

In some authoring situations it may be necessary to prompt (see clarification) or assist (e.g. task automation, entry storage, etc.) authors to follow accessible authoring practices. This is especially true of accessibility problems that require human judgment to remedy, such as adding descriptions to images. In general, it is preferable to begin guiding the author towards the production of accessible content before accessibility problems have actually been introduced. Postponing checking (checkpoint 3.2) and correcting (checkpoint 3.3) may leave the author uninformed of accessibility problems for so long that when the author is finally informed, the full weight of the accumulated problems may be overwhelming.

When information is required of the author, it is crucial that that information be correct and complete. This is most likely to occur if the author has been convinced to provide the information voluntarily. Therefore, overly restrictive mechanisms are not recommended for meeting this checkpoint.

Clarification of Term "Prompt":

The term prompt in this checkpoint should not be interpreted as necessarily implying intrusive prompts, such as pop-up dialog boxes. Instead, ATAG 2.0 uses prompt in a wider sense, to mean any tool initiated process of eliciting author input (see definition of prompting for more information).

Implementation Notes:

The checkpoints in guideline 4 require that implementations of prompting be:

Techniques for Success Criteria 1: When the actions of the author risk creating accessibility problems (e.g. image inserted, author typing invalid element into a code view, author initiating a page creation wizard, etc.), the tool must intervene to introduce the appropriate accessible authoring practice.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

Technique 3.1.1: Use an appropriate prompting and assisting mechanism

 

3.1.1(1): Prompting and assisting for short text labels (e.g. alternate text, titles, short text metadata fields, rubies for ideograms):

  • (a) Since prompts for short text strings are usually intended to elicit entries of ten words or less, they can be afforded relatively little screen real estate.
  • (b) A rendered view of the object can be provided for the author to examine while composing the label.
  • (c) Short text labels are a good candidate for storage and reuse (see Techniques for ATAG checkpoint 4.4)
  • (d) Automated routines can be implemented to detect and offer labels for objects serving special functions (e.g. "decorative", "button", "spacer", "horizontal rule", etc.).
  • (e) An editable text entry box with a drop-down list can accommodate new text entry as well as the option to select from reusable or special function label text.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.1.1(1a): This illustration shows an authoring interface for description reuse. It is comprised of a drop-down list that is shown with several short labels for the same image. Notice that one of the labels in the list is in a different language (i.e. French). The author must be able to create a new label, if the stored strings are not appropriate. (Source: mockup by AUWG)
Screen shot demonstrating prompting for short labels[longdesc missing]
Applicable to Code-Level authoring functions Example 3.1.1(1b): This illustration shows a code-based authoring interface for short text label prompting. The author has just typed quotation marks (") to close the href attribute. (Source: mockup by AUWG)
Screen shot demonstrating pop-up menu for selecting alt text.[longdesc missing]
 

3.1.1(2): Prompting and assisting for multiple text labels (e.g. image map area labels):

  • (a) Prompts for image map text labels can be similar to those for short text labels with allowance made for rapidly adding several labels for one image map.
  • (b) A preview of the image map areas can be provided.
  • (c) The URI of the image map areas can be provided.
  • (d) The tool can offer to automatically generate a set of plain text links from the labels.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.1.1(2): This illustration shows an authoring interface for image map area text label prompting. It is comprised of a list with two columns. In the right-hand column is the URL for each image map area. This can be used as a hint by the author as they fill in a label text entry in the left-hand column. A checkbox at the bottom provides the option of using this label text to create a set of text links below the image map. (Source: mockup by AUWG)
Screen shot demonstrating prompting for image map labels[longdesc missing]
 

3.1.1(3): Prompting and assisting for long text descriptions (e.g. longdesc text, table summaries, site information, long text metadata fields):

  • (a) The author can first be prompted as to whether the inserted object is adequately described. Providing a "no images" view of the page may help them decide.
  • (b) If the short description is inadequate, the author can be prompted for the location of a pre-existing description.
  • (c) If the author needs to create a description, a special writing utility can be provided (that can include a rendered view of the object and description writing pointers).
  • (d) Long descriptions are a good candidate for storage and reuse (see Techniques for ATAG checkpoint 4.4)
  • (e) Automated routines that detect and ignore some objects that do not require long text descriptions (e.g. bullets, spacers, horizontal rules).
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.1.1(3): This illustration shows an authoring interface for long text description prompting. A "description required" checkbox controls whether the rest of the interface is available. If a description is required, the author then has the choice of opening an existing description file or writing (and saving) a new one. (Source: mockup by AUWG)
Screen shot demonstrating prompting for long descriptions [longdesc missing]
Modify to show existing.
 

3.1.1(4): Prompting and assisting for form field labels:

  • (a) Present the form fields and ask the author to select text that is serving as a label or to enter a new label.
  • (b) Alert authors to form fields that are missing labels.
 
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Example 3.1.2(4): This illustration shows a form properties list that allows the user author to simultaneously decide the field labels, tab order, form field place holders and accesskeys. (Source: mockup by AUWG)
Demonstration of form labeling property list[longdesc missing]

@@Modify to show what happens when label is missing@@
 

3.1.1(5): Prompting and assisting for form field place-holders:

  • (a) Prompts for form field place-holders can be similar to those for short text labels.
  • (b) Authors could have the option of directly selecting nearby text strings that are serving implicitly as labels.
 

3.1.1(6): Prompting and assisting for TAB order sequence:

  • (a) The author can be provided with a numbering tool that they can use to select controls to create a TAB preferred sequence. (See Example 3.1.2(4))
  • (b) Where there are only a few links that change in each page of a collection, a tool can ask the author to confirm whether these links receive focus first. If so, then the tool can appropriately update the tabindex order.
  • (c) Provide a links/controls list to check the TAB order.

@@needs its own example@@
 

3.1.1(7): Prompting and assisting for navigational shortcuts (e.g. keyboard shortcuts, skip links, voice commands, etc.):

  • (a) Authors can be prompted with a list of links that are candidates for accesskeys because they are common to a number of pages in a site.
  • (b) Accesskey lists can be managed to ensure consistency across sites and to prevent conflicts within pages.(See Example 3.1.1(7b))
Applicable to Code-Level authoring functions Example 3.1.1(7b): This illustration shows a code-based authoring interface suggesting accesskey values. Notice that "m" is the first suggestion, as it is the first letter of the link text, "moon". "c" does not appear in the list as it is already used elsewhere in the document. (Source: mockup by AUWG)
Demonstration of an interface suggesting accesskeys[longdesc missing]

@@mistake in mockup - double moon@@

@@provide an example of (a)@@

@@link rel???, skip links@@
 

3.1.1(8): Prompting and assisting for contrasting colors:

  • (a) When a foreground or background color is defined the color choices provided to the author can be pre-screened for contrast.
  • (b) Color palettes can be assembled with problematic colors excluded (see Example 3.1.1(8)) or flagged.
  • (c) Provide gray scale and black and white views or suggest the author activate the system operating system high contrast mode.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.1.1(8): This illustration shows an authoring interface for choosing a text color. The palette has been filtered so that sufficient contrast between the text and the current background color is assured. (Source: mockup by AUWG)
Demonstration of high-contrast palette filter[longdesc missing]
 

3.1.1(9): Prompting and assisting for alternative resources for multimedia (transcripts, captions, video transcripts, audio descriptions, signed translations, still images, etc.):

  • (a) The author can be prompted for the location of a pre-existing alternative resources for multimedia (see Example 3.1.1(9)).
  • (b) Although producing alternative resource for multimedia can be a complex process for long media files, production suites do exist or authoring tools can include simple utilities, with built-in media players, for producing simple alternative resources.
  • (c) Alternative resources for multimedia are good candidates for storage and reuse (see Techniques for ATAG checkpoint 3.4)
  • (d) The tool should be able to access alternative resources for multimedia, which may be incorporated into existing media or exist separately.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.1.1(9): This illustration shows an authoring interface for embedding a video. The tool automatically detects whether captions, video transcript, described audio, or signed translation are present. For some items, links to utilities to create them are available. (Source: mockup by AUWG)
Demonstration of check for captions and descriptions[longdesc missing]

 
 

3.1.2(10): Metadata: [@@changed, metadata is actually just a special case of all the other things in this list @@] @@[@@OPEN WORK ITEM: LEFT HERE AS A PLACEHOLDER]@@

  • (a) 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.
  • (b) Metadata retrieval standards can be supported.
  • KM(new) (c) Check for DOCTYPE and refer to Help if author is unsure of which to choose
  • KM(new) (d) Check that Metatags do not violate WCAG such as refreshing not controllable by author.
 

3.1.1(11): Prompting and assisting for document structure:

[@@OPEN WORK ITEM: this could be greatly expanded to take into account highly structured (e.g. XSLT) authoring @@]

  • (a) The tool can offer to transform presentation markup that is misused to convey structure into structural markup (e.g. headings, sub-headings, etc.), with style sheets used to retain the same appearance.
  • (b) Formatting conventions such as a number of consecutive paragraphs beginning with a bullet character (this may be a "bullet" or another character like asterisk or dash "-") can be used to automatically identify lists.
  • (c) Authors of DTDs or Schemas can be prompted to specify explicit structure (e.g. nesting)
Applicable to 'what you see is what you get' authoring functionsExample 3.1.1(11): This illustration shows a tool that prompts for structural information. (Source: mockup by AUWG)
Demonstration of prompting for structural information [longdesc missing]
 

3.1.1(12): Prompting and assisting for tabular structure:

  • (a) The tool can prompt the author to identify tables as used for layout or data or implement automated detection mechanisms.
  • (b) Differentiate utilities for table structure from utilities for document layout - use this when tables are identified as being for layout. [STRONGLY SUGGESTED]
  • (c) The author can be prompted to provide header information.
  • (d) The author can be prompted to group and split columns, rows, or blocks of cells that are related.
  • (e) The tool can provide the author with a linearized view of tables (as tablin does).
Applicable to 'what you see is what you get' authoring functions Example 3.1.1(12): This illustration shows a tool that prompts the author as to whether the top row of a table is a row of table headers. (Source: mockup by AUWG)
Screen shot demonstrating a system for automatically adding table heading markup.[longdesc missing]
 

@@OPEN WORK ITEM:

3.1.1(13): Prompting and assisting for style sheets:

  • (a) The tool can offer to transform structural markup that is misused for style into style sheets (see "opposite" in 3.1.1(11)).
  • (b) The tool can allow the author to create style rules based on the formatting properties of an element and then apply the rule to other elements in the document.
  • (c) The tool can provide a utility for editing the layout and styling effects independently of the text content.
  • (d) Formatting patterns can be recognized and converted to style rules (e.g. ????).

BUCKET OF LOW DETAIL STUFF

  • The tool can offer prompting and/or assistance on using style sheets:
    • to control fonts, colors, text sizes
    • to specify fallback fonts to promote accessible content
    • to specify font characteristics to promote accessible content
    • and HTML elements to control fonts to promote accessible content
    • to usw color contrast to promote accessible content[@@move-see 3.1.2(9)@@]
    • specifying colors to promote accessible content[@@duplicate? - could all color related items be bundled in 3.1.2(9)@@]
    • specifying foreground and background contrast to promote accessible content[@@duplicate? - could all color related items be bundled in 3.1.2(9)@@]
    • specifying fore- and background colors to promote accessible content [@@duplicate? - could all color related items be bundled in 3.1.2(9)@@]
    • conveying information through multiple means (not just color)
    • using relative units of measure
    • using of absolute units of measure
    • creating stylized text with CSS rather than using raster images
    • formatting and positioning of text
    • using text style effects
    • creating rules and borders
    • using text equivalents for content generated by style sheets
    • using generated content in the DOM[@@move@@]
    • providing contextual clues in lists [@@move@@]
    • creating layout, positioning, layering, and alignment
    • creating null alt-text to promote accessible content[@@move - part of 3.1.2(1)@@]
    • providing good structural markup for graceful degradation to promote accessible content[@@move@@]
    • using scripting and style sheets
    • using ACSS to create auditory presentation
    • providing access to alternative representations of content [@@move@@]
    • using media types properly
 

3.1.1(14): Prompting and assisting for clearly written text: [@@changed@@]

  • (a) The author can be prompted to specify a default language of a document.
  • (b) A thesaurus function can be provided.
  • (c) A dictionary lookup system can recognize changes of language, terms outside a controlled vocabulary as well as known abbreviation or acronym expansions.
  • (d) The author can be prompted for expansions of unknown acronyms, recognizable in some languages as collections of uppercase letters.
  • (e) Provide an automated reading level status.
Applicable to Code-Level authoring functions Example 3.1.1(14): This illustration shows an authoring interface for indicating the reading level of a page and whether it exceeds a limit determined by the author's preference settings. (Source: mockup by AUWG)
[longdesc missing]
 

[@@OPEN ISSUE - needs to be strong to cover us in the programming lang area@@]

3.1.1(15): Prompting and assisting for device independent handlers:

  • (a) During code development, the author can be prompted to include device-independent means of activation.
  • (b) Storage and reuse of accessible code, scripts, etc.
Example needed.
 

3.1.1(16): Prompting and assisting for non-text supplements to text:

  • (a) The tool can prompt authors to provide icons for buttons, illustrations for text, graphs for numeric comparisons, etc.
  • (b) Where subject metadata is available, the tool can look up appropriate illustrations.
  • (c) If the author has identified content as instructions then the tool can provide templates or automated utilities for extracting flow charts, etc.
Applicable to 'what you see is what you get' authoring functions Example 3.1.1(16): This illustration shows an authoring interface for prompting the author as to whether a number-rich paragraph might be made more clear with the addition of a chart or graph. (Source: mockup by AUWG)
Screen shot demonstrating a system that prompts for visual alternatives.[longdesc missing]
@@Add metadata example(b)@@
 

3.1.1(17): Prompting and assisting for other types of accessibility information: [@@want to keep but not sure where@@]

  • (a) Where regions are not easily defined, the author can be asked 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, for a geographic map the input might be used to look up latitude and longitude of a point and then give information about that point.
  • Prompt for server-side alternatives for essential client-side scripts (those used for content and navigation) and applets.
  • (b) The author can be asked to provide a link to skip over objects (since some browsers cause objects to permanently capture the tab focus).
  • (c) The author can be prompted 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.
  • (d) When frames are used for a mosaic of images, the tool can allow inclusion of markup files (with images embedded) rather than images directly.
  • (e) Warn about adjacent links.
 

3.1.1(18): Prompting and assisting the author to make use of up to date formats:

Use technologies according to specification.- This is likely to be handled by the choices made by the tool developers. General-purpose text editors (e.g. emacs, etc.) would need to make technology selection recommendations.

@@BF: maybe add section to 3.1.1 about guiding author towards use of XML/XSLT (i.e. most up to date formats)@@
 

Technique 3.1.2: The tool can provide multiple preview modes and a warning to authors that there are many other less predictable ways in which a page may be presented (aurally, text-only, text with pictures separately, on a small screen, on a large screen, etc.). Some possible document views include:

  • an alternative content view (with images and other multimedia replace by any alternative content),
  • a monochrome view (to test contrast),
  • a collapsible structure-only view,
  • no scripts view
  • no frames view
  • no style sheet view
Applicable to 'what you see is what you get' authoring functionsExample 3.1.2: This illustration shows a WYSIWYG authoring interface with a list of rendering options displayed. The options include "All" (i.e. render as in a generic browser), "text-only" (i.e. non-text items replaced by textual equivalents), "no styles", "no frames" and "grayscale" (used to check for sufficient contrast). (Source: mockup by AUWG)
Illustration shows an authoring tool with a drop down menu of different rendering options[longdesc missing]
 

Techniques for Success Criteria 2: The intervention must occur at least once before completion of authoring (e.g. final save, publishing, etc.).

[@@Techniques needed@@] If prompting is left beyond the insertion of content containing an accessibility problem, checking becomes involved. For this reason, consider the timing techniques for checking (3.2.2) [@@clean up wording@@]

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.1.3: If author turns off any regularly scheduled checks in the configuration section, the tool must have a built-in method that cannot be turned off. (i.e. the author might not want to have any help throughout the entire authoring process, but there should be one last check that cannot be turned off.)
  Technique 3.1.4: The author can be prompted if content is closed.

 

ATAG Checkpoint 3.2: Check for and inform the author of accessibility problems. [Relative Priority]

Executive Summary:

Despite prompting assistance from the tool (see Checkpoint 3.1), accessibility problems may still be introduced. For example, the author may cause accessibility problems by hand coding or by opening content with existing accessibility problems for editing. In these cases, the prompting and assistance mechanisms that operate when markup is added or edited (i.e. insertion dialogs and property windows) must be backed up by a more general checking system that can detect and alert the author to problems anywhere within the content (e.g. attribute, element, programmatic object, etc.). It is preferable that this checking mechanisms be well integrated with correction mechanisms (see Checkpoint 3.3), so that when the checking system detects a problem and informs the author, the tool immediately offer assistance to the author.

Implementation Notes:

The checkpoints in guideline 4 require that implementations of checking be:

Techniques for Success Criteria 1: The tool must provide a check ( automated check, semi-automated check or manual check) for detecting violations of each requirement of WCAG.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

Technique 3.2.1: Automate as much checking as possible. Where necessary provide semi-automated checking. Where neither of these options is reliable, provide manual checking.
1. Automated: In automated checking, the tool is able to check for accessibility problems automatically, with no human intervention required. This type of check is usually appropriate for checks of a syntactic nature, such as the use of deprecated elements or a missing attribute, in which the meaning of text or images does not play a role.
Applicable to Code-Level authoring functions Example 3.2.1(c): This illustration shows a summary interface for a code-based authoring tool that displays the results of an automated check. (Source: mockup by AUWG)
Screen shot demonstrating automated checking with the results in a summarized list. [longdesc missing]
Applicable to 'what you see is what you get' authoring functions Example 3.2.1(d): This illustration shows an interface that displays the results of an automated check in a WYSIWYG authoring view using blue squiggly highlighting around or under rendered elements, identifying accessibility problems for the author to correct. (Source: mockup by AUWG)
Screen shot demonstrating automated checking in a WYSIWYG tool.[longdesc missing]
Applicable to Code-Level authoring functions Example 3.2.1(e): This illustration shows an authoring interface of an automated check in a code-level authoring view. In this view, the text of elements with accessibility problems is shown in a blue font, instead of the default black font. (Source: mockup by AUWG)
[longdesc missing]
2. Semi-Automated: In semi-automated checking, the tool is able to identify potential problems, but still requires human judgment by the author to make a final decision on whether an actual problem exists. Semi-automated checks are usually most appropriate for problems that are semantic in nature, such as descriptions of non-text objects, as opposed to purely syntactic problems, such as missing attributes, that lend themselves more readily to full automation.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.2.1(b): This illustration shows a dialog box that appears once the tool has detected an image without a description attribute. However, since not all images require description, the author is prompted to make the final decision. The author can confirm the at this is indeed an accessibility problem and move on to the repair stage by choosing "Yes". (Source: mockup by AUWG)
Screen shot demonstrating a semi-automated check[longdesc missing]

3. Manual: In manual checking, the tool provides the author with instructions for detecting a problem, but does not automate the task of detecting the problem in any meaningful way. As a result, the author must decide on their own whether or not a problem exists. Manual checks are discouraged because they are prone to human error, especially when the type of problem in question may be easily detected by a more automated utility, such as an element missing a particular attribute.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.2.1(a): This illustration shows a dialog box that reminds the author to check if there are any words in other languages in the document. The author can move on to the repair stage by pressing "Yes". (Source: mockup by AUWG)
Screen shot demonstrating manual check[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.2: Consider the timing options to be used for informing the author of the results of the check. Options include: Immediate Interruption, Negotiated Interruption and Scheduled Interruption.[@@new@@]

1. Immediate Interruption: An immediate interruption is the most intrusive timing option because the attention of the author is actively diverted from the current editing task by the notification of some issue. This might be achieved, for instance, by an alert dialog. This type of alert presents multiple usability problems and should be used sparingly because it interferes with the normal design workflow. Intrusive warnings are probably only appropriate when the window of opportunity for correcting a serious accessibility problem is about to close, such as when an author decides to publish the content in question. In general, we recommend using the less disruptive timing options.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.2.2(a): This illustration shows an example of an immediate interruption of the author's workflow. The author must press the "OK" button on the dialog box to continue. (Source: mockup by AUWG)
Screen shot demonstrating an immediate interruption[longdesc missing]

2. Negotiated Interruption (Preferred): A negotiated interruption is caused by interface mechanisms (icons, line or color highlighting of the element, audio feedback, etc.) that alert the author to a problem, but remain flexible enough to allow the author to decide whether to take immediate action or address the issue at a later time. Since negotiated interruptions are less intrusive than immediate interruptions they can often be better integrated into the design workflow and have the added benefit of informing the author about the distribution of errors within the document. Although some authors may choose to ignore the alerts completely, it is not recommended that authors be forced to fix problems. Instead, it is recommended that, at some major editing event (e.g., when publishing), the tool should remind the author of the continuing unresolved accessibility issue.

Applicable to 'what you see is what you get' authoring functions Example 3.2.2(b): This illustration shows an example of a negotiated interruption. The author is made aware of problems detected automatically by means of a blue squiggly line around or under rendered elements with accessibility problems. The author can still decide to address the problems at a later time. (Source: mockup by AUWG)
Screen shot demonstrating coconfigured interuption[longdesc missing]

3. Scheduled Interruption: A scheduled interruption is one in which the author has set the tool to alert them of accessibility issues on a configurable schedule. One option for the schedule might be to have prompts associated with the interface mechanisms for significant authoring events such as saving, exiting, publishing, or page generation, etc. At the significant authoring event, the author would be informed of the problem, while at the same time they would not be prevented from saving, publishing, printing, etc. For example, a "save as" dialog could display an accessibility warning and an option to launch a correction utility after saving (see Figure 3.2.7). A potential downside of this type of prompting is that by the time the prompt is displayed (publishing, etc.), the author may not have sufficient time to make the required changes, especially if they are extensive.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Example 3.2.2(c): This illustration shows a "Save As" dialog box that is an example of a scheduling mechanism for a scheduled interruption. The author has the option of turning on or off a checking session immediately following the save operation. The author's preference should be retained for the next save operation. (Source: mockup by AUWG)
Screen shot demonstrating a save as dialog with accessibility warning message[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.3: The Techniques For Accessibility Evaluation And Repair Tools [WAI-ER] Public Working Draft document can be consulted for evaluation and repair algorithms related to WCAG 1.0. The WAI Evaluation and Repair group [WAI-ER] is developing a document that discusses detailed techniques for testing the accessibility of content according to the Web Content Accessibility Guidelines, and methods of repairing it. A draft of that document is available [AUTO-TOOL].
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.4: Accessibility problems can be detected and immediately highlighted when documents are opened, when an editing or insertion action is completed, or while an author is editing. CSS classes can be used to indicate accessibility problems enabling the author to easily configure the presentation of errors.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.5: The author can be alerted to accessibility problems when saving.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.6: Accessibility problems can be highlighted using strategies similar to spell checking within a word processor.@@covered in GL4?@@
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

New Technique: Accessibility alerts within the document can be linked to context sensitive help. (See the Techniques for ATAG checkpoint 6.1)

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.7: Where the tools cannot test for accessibility errors the author with the necessary information, wizards, etc. to check for themselves. @@covered in discussion of types of prompts@@
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.8: Alerts for high priority WCAG checkpoints can be included in the default configuration.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.9: Provide an editing view that shows equivalent alternatives in the main content view to make it clear that they are necessary. This will make it obvious when they are missing. @@covered in technique 3.1.3?@@
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.10: Preference utilities can be designed to allow authors to choose different alert levels based on the priority of authoring accessibility recommendations.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.11: If intrusive warnings are used, a means can be provides for the author to quickly set the warning to unobtrusive to avoid frustration.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.2.12: The WAI Evaluation and Repair group has produced a Public Working Draft of techniques for evaluating and repairing HTML according to WCAG 1.0 [AERT]. @@duplicate of 3.2.3@@

 

ATAG Checkpoint 3.3: Assist authors in correcting accessibility problems. [Relative Priority]

Executive Summary:

Once a problem has been detected by the author or, preferably, the tool (see Checkpoint 3.2), the tool may assist the author to correct the problem. As with accessibility checking, the extent to which accessibility correction can be automated depends on the nature of the particular problems. Some repairs are easily automated, whereas others that require human judgment may be semi-automated at best.

Implementation Notes: @@NEW@@

The checkpoints in guideline 4 require that implementations of correcting be:

Techniques for Success Criteria 1: The tool must provide a repair (automated repair, semi-automated repair or manual repair) for correcting violations of each requirement of WCAG.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.1: Consider the level of automation to be used for repairing errors. Options include: Manual, Semi-Automated and Automated.[@@new@@]

1. Manual: In manual repairing, the tool provides the author with instructions for making the necessary correction, but does not automate the task in any substantial way. For example, the tool may move the cursor to start of the problem, but since this is not a substantial automation, the repair would still be considered "manual". Manual correction tools leave it up to the author to follow the instructions and make the repair by themselves. This is the most time consuming option for authors and allows the most opportunity for author error.
Applicable to Code-Level authoring functions Example 3.3.1(a): This illustration shows a sample manual repair. The problems have already been detected in the checking step and the selected the offending elements in a code view have been highlighted. However, when it comes to repairing the problem, the only assistance that the tool provides is a context sensitive hint. The author is left to make sense of the hint and perform the repair without any automated assistance. (Source: mockup by AUWG)
Screen shot demonstrating manual repair advice.[longdesc missing]

2. Semi-Automated: In semi-automated repairing, the tool can provide some automated assistance to the author in performing corrections, but the author's input is still required before the repair can be complete. For example, the tool may prompt the author for a plain text string, but then be capable of handling all the markup required to add the text string to the content. In other cases, the tool may be able to narrow the choice of repair options, but still rely on the author to make the final selection. This type of repair is usually appropriate for corrections of a semantic nature.
Applicable to 'what you see is what you get' authoring functions Example 3.3.1(b): This illustration shows a sample of a semi-automated repair in a WYSIWYG editor. The author has right-clicked on an image highlighted by the automated checker system. The author must then decide whether the label text that the tool suggests is appropriate. Whichever option the author chooses, the tool will handle the details of updating the content. (Source: mockup by AUWG)
Screen shot demonstrating semi-automated repair[longdesc missing]
3. Automated: In automated tools, the tool is able to make repairs automatically, with no author input required. For example, a tool may be capable of automatically adding a document type to the header of a file that lacks this information. In these cases, very little, if any, user authoring interface is required. This type of repair is usually appropriate for corrections of a syntactic or repetitive nature.
Applicable to Code-Level authoring functions Example 3.3.1(c): This illustration shows a sample of an announcement that an automated repair has been completed. An "undo " button is provided in case the author wishes to reverse the operation. In some cases, automated repairs might be completed with no user authoring interface presence at all. (Source: mockup by AUWG)
Screen shot demonstrating automated checking.[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.2: Consider implementing a special-purpose correcting interface. [@@new@@]When problems require some human judgment, the simplest solution is often to display the property editing mechanism for the offending element. This has the advantage that the author is already somewhat familiar with the interface. However, this practice suffers from the drawback that it does not necessarily focus the author's attention on the dialog control(s) that are relevant to the required correction. Another option is to display a special-purpose correction utility that includes only the input field(s) for the information currently required. A further advantage of this approach is that additional information and tips that the author may require in order to properly provide the requested information can be easily added. Notice that in the figure, a drop-down edit box has been used for the short text label field. This technique might be used to allow the author to select from text strings used previously for the alt-text of this image (see ATAG Checkpoint 3.5 for more).
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.3.2: This illustration shows a sample of a special-purpose correction interface. The tool supports the author's repair task by providing a description of the problem, a preview (in this case of the image missing a label), tips for performing the repair, possible repair options (archived from previous repairs) and other information (in this case the name of the image file). (Source: mockup by AUWG based on A-Prompt)
Screen shot demonstrating a page from a dedicated accessibility prompting checker[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.3: Checks can be automatically sequenced.@@changed@@
In cases where there are likely to be many accessibility problems, it may be useful to implement a checking utility that presents accessibility problems and repair options in a sequential manner. This may take a form similar to a configuration wizard or a spell checker (see Figure 3.3.5). In the case of a wizard, a complex interaction is broken down into a series of simple sequential steps that the author 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 author 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 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 "change to" word. The author also has correcting options, some of which can store responses to affect how the same situation can be handled later. In an accessibility problem checker, sequential prompting is an efficient way of correcting problems. However, because of the wide range of problems the checker needs to handle (i.e. missing text, missing structural information, improper use of color, etc.), the interface template will need to be even more flexible than that of a spell checker. Nevertheless, the template is still likely to include areas for identifying the problem (WYSIWYG or code-based according to 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.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.3.3: This illustration shows an example of a sequential accessibility checker, the special-purpose correction interface from Example 3.3.2 is supplemented with navigational controls for moving backwards and forwards through the list of repair tasks. (Source: mockup by AUWG based on A-Prompt)
Screen shot demonstrating Screen shot demonstrating dedicated accessibility checker[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

Technique 3.3.4: When authoring tools produce content in real-time, it is usually no longer possible to delay addressing accessibility problems until arbitrary point in the future. At the same time, due to the time pressure, authors in real-time environments tend to be less receptive to intrusive prompts. Nevertheless, tools that allow this kind of authoring (see Figure 3.3.6) should still take accessibility issues into account by supporting the following:

  • Determination of Participant Requirements: If real-time authoring is consumed by individuals with no special communicative needs, there may be no need for real-time prompting. However, as with any other Web content it is often impossible for the author to know all of the needs of the actual or potential participants. Therefore, the best practice is to create real-time content that conforms with WCAG to the greatest extent possible. However, when this is not possible, real-time authoring tool might be able to facilitate graceful degradation of accessibility by polling the participants (see "Request whiteboard descriptions" checkbox in the figure) or in some cases checking the profiles of participants @@REF@@ to determine which types of accessibility practices would offer the greatest advantage in the the short time available. Once this information is compiled, the tool can prompt the author or see Assistant/Peer Author) to correct problems appropriately (preferably during Preparation Time). When it is not possible to know, with certainty, the needs of all participants, the tool should still assume that accessible content is required. This is especially true if the results of the session will be archived.
  • Assistant/Peer Author: In some cases, it may be possible to designate one or more secondary authors in the live community, who can receive and respond to prompts for supplemental information generated as the primary author proceeds uninterrupted. The secondary author might be an unrelated specialist, analogous to Sign language interpreter, a co-author (helpful for describing technical drawings, etc.), or in some situations any member of the session audience (i.e. a peer).
  • Preparation Time: If the authoring tool allows the author time to pre-assemble materials for a live presentation (e.g. a professor preparing for an online class), this authoring is not considered real-time authoring. The authoring tool has the opportunity and the obligation to support accessible authoring as described elsewhere in this document.
  • Archiving: If the session will be archived, there may be other opportunities to increase the accessibility of the content of the archive by guiding the author through a process to check for and repair accessibility problems after the real-time session has ended, but prior to archiving.

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:

  • Implementing the equivalent alternatives management functionality (see Checkpoint 3.5). This way, if the author uses an object that has been used before, the tool can suggest the previously stored alternative, which the author can quickly accept or decline without substantial workflow disruption.
  • Providing a voice recognition capability so that the author's real-time speech input can be converted into captioning.
Applicable to 'what you see is what you get' authoring functions Example 3.3.4: This illustration shows an a real-time presentation in a whiteboard/chat environment. Notice the functionality by which the presenter or a secondary author (describer) can describe the events on the whiteboard even as the dialog continues. (Source: mockup by AUWG, based on A-Communicator).
Screen shot demonstrating ad whiteboard/chat tool with whiteboard description prompting [longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.5: At a minimum, provide context-sensitive help with the accessibility checking required by ATAG Checkpoint 3.2.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.6: Where a tool is able to detect site-wide errors, allow the author to make site-wide corrections. This should not be used equivalents alternatives when the function is not known with certainty (see ATAG Checkpoint 3.4). [@@changed@@]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.7: Assist authors in ways that are consistent with the look and feel of the authoring tool (See Techniques for ATAG Checkpoint ?.?).
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.8: Allow authors to configuration the nature and timing of the correction process.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.3.9: Provide a mechanism for authors to navigate sequentially among uncorrected accessibility errors.
  Technique 3.3.10: The WAI Evaluation and Repair group [WAI-ER] has produced a Public Working Draft of techniques for evaluating and repairing HTML according to WCAG 1.0 [AERT].@@see 3.2.3@@

 

ATAG Checkpoint 3.4: Do not automatically generate equivalent alternatives or reuse previously authored alternatives without author confirmation, except when the function is known with certainty. [Priority 1]

Techniques for Success Criteria 1: When the author inserts an unrecognized non-text object, the tool must not insert an automatically generated text equivalent (e.g. label generated from the file name).

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.4.1: If the author has not specified an alternative equivalent, default to leaving out the relevant content (e.g. attribute, element, etc.), rather than including the attribute with no value or with automatically-generated content. Leaving out the attribute will increase the probability that the problem will be detected by checking algorithms (see Techniques for ATAG checkpoint 5.1).

Techniques for Success Criteria 2: When the author inserts a non-text object for which the tool has a previously authored equivalent (i.e. created by the author, tool designer, pre-authored content developer, etc.), but the function of the object is not known with certainty, the tool must prompt the author to confirm insertion of the equivalent. However, where the function of the non-text object is known with certainty (e.g. "home button" on a navigation bar, etc.), the tool may automatically insert the equivalent.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.4.2: If human-authored equivalent alternatives are available for an object (for example, through Techniques for ATAG checkpoint 4.4 and/or Techniques for ATAG checkpoint 3.4), the equivalent alternatives can be used in both semi-automated repair processes and automated repair processes as long as the function of the object is known with certainty. The function of an instance of an object can be considered to be known with certainty when the tool totally controls its use (i.e. a generated tool bar) or the author has linked the current object instance to the same URI(s) as the object was linked to when the equivalent alternative was stored. @@ BAF: suggest the author marking the content with a role/flag to insure certainty. @@
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.4.3: If human-authored equivalent alternatives are available for an object and that object is used for a function that is not known with certainty, tools can offer the equivalent alternatives to the author as defaults in a semi-automated repair processes, but not not in fully automated repair processes.
  NEW(@@was part of 3.4.3@@) Technique 3.4.4: Where an object has already been used in a document, the tool can offer the alternative information that was supplied for the first or most recent use as a default.
  NEW(@@was part of 3.4.3@@) Technique 3.4.5: If the author changes the alternative content, the tool can ask the author whether all instances of the object should have their alternative content updated with the new value.

 

ATAG Checkpoint 3.5: Provide functionality for managing, editing, and reusing equivalent alternatives for multimedia objects. [Priority 3]

Executive Summary:

Note: This checkpoint is priority 3 and is, therefore, not required to be implemented in order for a tool to conform to ATAG 2.0 at the single-A and double-AA levels. However, implementing this checkpoint has the potential to simplify the satisfaction of several higher priority checkpoints (ATAG checkpoint 3.1, ATAG checkpoint 3.2, and ATAG checkpoint 3.3) and improve the usability of the tool.

Techniques for Success Criteria 1: When non-text objects have been previously inserted using the tool, the tool must suggest any previously authored textual equivalents for that non-text object.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.5.1: A registry can be maintained that associates object identity information with alternative information (this could be done with the Resource Description Framework (RDF) [RDF10]). Whenever an object is used and an equivalent alternative is collected (see ATAG Checkpoint 3.1) the object (or identifying information) and the alternative information can be added to the registry. In the case of a text equivalent, the alternate information can be stored in the document source. For more substantial information (such as video captions or audio descriptions), the information can be stored externally and linked from the document source. Several different versions of alternative information can be associated with a single object.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Example 3.5.1: This illustration shows a of a text equivalents registry viewer that a tool can include to allow the author to query and edit the various text equivalents stored in the registry. For maximum flexibility, the design takes into account multiple non-text objects of the same name, multiple types of text equivalents for each non-text object, and multiple versions of each text equivalent type. (Source: mockup by AUWG)
Illustration of a text equivalents registry editing tool[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.5.2: Stored alternative information can be presented to the author as default text in the appropriate field, whenever one of the associated files is inserted into the author's document. This satisfies ATAG Checkpoint 3.4 because the equivalent alternatives are not automatically generated and they are only reused with author confirmation.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

Technique 3.5.3: If no stored association is found in the registry, the field can be left empty. No purely rule-generated alternative information is allowed.

Note: The term "default" implies that the alternative information is offered for the author's approval. The term does not imply that the default alternative information is automatically placed without the author's approval. Such automatic placement may only occur when in situations where the function of the object is known with certainty, per ATAG Checkpoint 3.4. Such a situation might arise in the case of a "navigation bar builder" that places a navigation bar at the bottom of every page on a site. In this case, it would be appropriate to use the same "alt"-text automatically for every instance of a particular image (with the same target) on every page.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.5.4: The stored alternative information required for ATAG Checkpoint 3.4 might be part of the management system, allowing the alternative equivalents to be retrieved whenever the pre-packaged objects are inserted.
  Technique 3.5.5: Tools might allow authors to make keyword searches of a description database (to simplify the task of finding relevant images, sound files, etc.). A paper describing a method to create searchable databases for video and audio files is available (refer to [SEARCHABLE]).

 

ATAG Checkpoint 3.6 : Provide the author with a summary of the document's accessibility status. [Priority 3]

Techniques for Success Criteria 1: The tool must provide the author with an option to view a listing of all current accessibility problems.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.6.1: A list of all accessibility errors found in within the content (e.g. selection, document, site, etc.) can be provided.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.6.2: A summary of accessibility problems remaining by type and/or by number can be provided.

 

ATAG Checkpoint 3.7 : Document all features that promote the production of accessible content. [Priority 1]

Implementation Notes: @@NEW@@

The checkpoints in guideline 4 require that implementations of documentation be:

Techniques for Success Criteria 1: All features that play a role in creating accessible content must be documented in the help system.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.7.1: Ensure that the help system can answer the following questions: "What features of the tool encourage the production of accessible content?" and "How are these features operated?".
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.7.2: Provide direct links from the features to context sensitive help on how to operate the features. (i.e., the link might originate with icons, outlining or other emphasis within the authoring interface).
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.7.3: Provide links from within the help text to relevant automated correction utilities.

 

ATAG Checkpoint 3.8: Ensure that accessibility is modeled in all documentation and help, including examples. [Priority 2]

Techniques for Success Criteria 1: All examples of markup code and views of the user authoring interface (dialog screenshots, etc.) must meet the requirements of WCAG, regardless of whether the examples are intended to demonstrate accessibility authoring practices.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions

Technique 3.8.1@@was 4.1.4@@: Documentation can include relevant accessible authoring practices.
Applicable to Code-Level authoring functions Example 3.8.1: This illustration shows documentation for the INPUT element in this code-level authoring tool makes use of the LABEL element in order to reinforce the routine nature of the pairing. (Source: mockup by AUWG)
Screen shot demonstrating a help systme for the 'input' element.[longdesc missing]
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.1: In the documentation, ensure that all code examples pass the tool's own accessibility checking mechanism (required for checkpoint 3.1), regardless of what aspect of the code the example is meant to show.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.2: In the documentation, provide at least one model of each accessibility practice in the relevant WCAG techniques document for each language supported by the tool. Note: This includes all levels of accessibility practices, not just Level 1 or 2.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.3: When the help files of a base tool do not meet this checkpoint, an accessibility plug-in that updates the files is acceptable.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.4: When explaining the accessibility issues related to elements that have not been officially deprecated, try to emphasize the solutions rather than explicitly discouraging the use of the element.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.6: For tools that include context sensitive help, implement context-sensitive help for accessibility terms as well as tasks related to accessibility.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.7: For tools that include tutorials, provide a tutorial on checking for and correcting accessibility problems.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.8: Include pointers to more information on accessible Web authoring, such as WCAG and other accessibility-related resources,
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.8.9: Include current versions of, or links to relevant language specifications in the documentation. This is particularly relevant for languages that are easily hand edited, such as most XML languages.

 

ATAG Checkpoint 3.9: Document the workflow process of using the tool to produce accessible content. [Priority 3]

Techniques for Success Criteria 1: The documentation must contain suggested content creation workflow descriptions that include how and when to use the accessibility-related features of the tool.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.9.1: Document the sequence of steps that the author should take, using the tool, in order to increase the likelihood of producing accessible content. This should take account of any idiosyncrasies of the tool.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.9.2: The section could be prefaced by an introduction that explains the importance of accessibility for a wide range of content consumers, from those with disabilities to those with alternative viewers.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.9.3: For tools that explain the reasons for accessibility, take a broad view. For example, do not refer to any particular accessibility feature as being "for blind authors" or label them with a "disability" icon. Instead, refer to them as being for "authors who are not viewing images". Consider emphasizing points in "Auxiliary Benefits of Accessibility Features", a W3C-WAI resource.
Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.9.4: This documentation could be located in a dedicated section.

Techniques for Success Criteria 2: For tools that lack a particular accessibility-related feature, the workflow description must include a workaround for that feature.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Applicable to Indirect authoring functions Technique 3.9.5: Tools that lack an accessibility checking and/or repair feature may point to the relevant WCAG Techniques document for the language. Note: this will not suffice to meet the checkpoints related to accessibility checking (ATAG Checkpoint 3.1) and repair (ATAG Checkpoint 3.2).

 

Contents | Guideline 1 | Guideline 2 | Guideline 3 | Guideline 4 | References