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

W3C

Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0

Guideline 3: Support the production of accessible content.

W3C Working Draft 14 March 2003

This version:
http://www.w3.org/TR/2003/WD-ATAG20-TECHS-20030314/tier3
Latest version:
http://www.w3.org/TR/ATAG20-TECHS/tier3
ATAG 1.0 Recommendation:
http://www.w3.org/TR/ATAG10
Editors of this chapter:
Jan Richards
Charles McCathieNevile

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

Guiding the author to produce accessible content:

ATAG Checkpoint 3.1: Prompt and assist the author to avoid accessibility problems when they add or edit content. [Relative Priority]

Executive Summary:

Author assistance may take many forms, depending on the nature of the accessibility problem and the design of the tool. While the most visible form of assistance will likely be user prompting, other kinds of assistance are possible.(???)avoid accessibility problems will require that the tool elicit extra information from the author by promptingThis is especially true in the case of accessiblity problems that often require human judgement to remedy, such as especially accessible equivalents for images.

It is preferable to begin guiding the author towards the production of accessible content before the content is actually inserted. Otherwise, if the author is left uninformed of accessibility problems for too long, then when they are finally informed, they may be overwhelmed by the full weight of the accumulated problems. Note: It is important to note that when information is required from 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.

Clarification

The prompt aspect of "Prompt and assist" should not be confused with the narrow software sense of the term 'prompt'. Instead, ATAG 2.0 uses prompt in a wider sense, to mean the process of eliciting author input. This process should be:

Furthermore, this process should be implemented in a way that causes the author to develop a positive disposition and awareness towards accessible authoring practices.

User Configurability:

User acceptance of the accessibility features of an authoring tool will likely depend on the degree to which these features can be integrated into authors' existing workflows. That is why the ATAG definition of "prompting" clearly states that: "the form and timing that this prompting takes can be user configurable". In other words, the author should be able to control to some extent how and when assistance in avoiding accessibility problems is rendered by the tool. This user configurablity will help reconcile the additional accessibility authoring tasks with the regular work pattern of the author. To achieve this, tools may offer the author a range of checking and prompting options (see Figure 3.1.1), including:

Fig. 1: Accessibility options card.Figure 3.1.1: Example of an accessibility preferences dialog. [d]
(Source: mockup by AUWG)

Techniques (WCAG v2.0):

WCAG Guideline 1 - Perceivable. Ensure that all intended function and information can be presented in form(s) that can be perceived by any user - except those aspects that cannot be expressed in words.
WCAG Checkpoint 1.1 - For all non-text content that can be expressed in words, provide a text equivalent of the function or information the non-text content was intended to convey.

screen shot demonstrating prompting for short labelsFigure 3.1.2: [d]

screen shot demonstrating prompting for long descriptionsFigure 3.1.3: [d]

screen shot demonstrating prompting for image map labelsFigure 3.1.4: [d]

Figure: ?

Figure: ?
WCAG Checkpoint 1.2 - Provide synchronized media equivalents for time-dependent presentations.

Figure: ?

Figure: ?

Figure: ?
WCAG Checkpoint 1.3 - Make all content and structure available independently of presentation.

Figure: ?
WCAG Checkpoint 1.4 - Emphasize structure through presentation(s), positioning, and labels.
WCAG Checkpoint 1.5 - Ensure that foreground content is easily differentiable from background for both auditory and visual presentations.
WCAG Checkpoint 1.6 - Provide information needed for unambiguous decoding of the characters and words in the content.
WCAG Guideline 2 - Operable. Ensure that the interface elements in the content are operable by any user.
WCAG Checkpoint 2.1 - Ensure that all of the functionality of the content is operable through character input to the content or user agent.
WCAG Checkpoint 2.2 - Allow users to control any time limits on their reading, interaction or responses unless control is not possible due to the nature of real-time events or competition.
WCAG Checkpoint 2.3 - Avoid causing the screen to flicker.
WCAG 2.0 Guideline 3 - Navigable. Facilitate content orientation and navigation
WCAG Checkpoint 3.1 - Provide structure within content.
WCAG Checkpoint 3.2 - Provide multiple methods to explore sites that are more than two layers deep.
WCAG Checkpoint 3.3 - Use consistent but not necessarily identical presentation.
WCAG Checkpoint 3.4 - Provide consistent and predictable responses to user actions.
WCAG Checkpoint 3.5 - Provide methods to minimize error and provide graceful recovery.
WCAG 2.0 Guideline 4 - Understandable. Make it as easy as possible to understand the content and controls.
WCAG Checkpoint 4.1 - Write as clearly and simply as is [appropriate / possible] for the purpose of the content.
WCAG Checkpoint 4.2 - Supplement text with non-text content.

Figure: ?
WCAG Checkpoint 4.3 - Annotate complex, abbreviated, or unfamiliar information with summaries and definitions.
WCAG 2.0 Guideline 5 - Robust. Use Web technologies that maximize the ability of the content to work with current and future accessibility technologies and user agents.
WCAG Checkpoint 5.1 - Use technologies according to specification.
WCAG Checkpoint 5.2 - Ensure that technologies relied upon by the content are declared and widely available.
WCAG Checkpoint 5.3 - Choose technologies that are designed to support accessibility.
WCAG Checkpoint 5.4 - Ensure that user interfaces are accessible or provide an accessible alternative.

Other Techniques for Providing Assistance:

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

Executive Summary:

Despite assistance from the tool (see Checkpoint 3.1), accessibility problems may still be introduced (e.g. by the author during hand coding or content authored by other tools is imported). In these cases, the 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 (attribute, element, programmatic object, etc.).

Ideally, checking mechanisms should be highly integrated with correction mechanisms (see Checkpoint 3.3) so that when the system detects a problem and informs the author, the tool also helps the author address the issue.

Levels of Automation:

Accessibility checking may be achieved with varying levels of automation: manual, semi-automated and fully automated (preferred):

  1. Manual: 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 (see Figure 3.2.1). As a result, the author must follow the instructions and make the determination that a problem exists by themselves. This type of check is discouraged since it can be annoying for the author, especially when the type of problem in question may be easily detected by a more automated utility (e.g. an element missing a particular attribute).

    Example of a manual checkFigure 3.2.1: Example of a manual check. [d]
    (Source: mockup by Jan Richard)
  2. Semi-Automated: The tool is able to identify potential problems, but still requires a human judgment by the author to make a final appraisal (see Figure 3.2.2). This type of check is usually most appropriate for semantic-type problems, such as descriptions of non-text objects, as opposed to purely syntactic problems, such as missing attributes, which lend themselves more readily to automation.

    Example of a semi-automated checkFigure: 3.2.2: Example of a semi-automated check. [d]
    (Source: mockup by AUWG)
    @@fix image text@@
  3. Automated (Preferred): The tool is able to check for accessibility problems automatically, with no human intervention required (see Figure 3.2.3). This type of check is usually appropriate for syntactic-type checks, such as the use of deprecated elements or a missing attribute, in which the meaning of text does not play a role.

    Example of a fully automated checkScreenshot of code view with font color accessibility highlightingFigure: 3.2.3: Example of a fully automated check. [d]
    (Source: mockup by AUWG)

Timing Options for "Informing" the Author:

Accessibility checking mechanisms may use make use of different timing options: immediate interruption, negotiated interruption (preferred), and scheduled interruption:

  1. Immediate Interruption: An immediate interruption is the most intrusive timing option because the author's attention is actively diverted from the current editing task by the notification of some issue. This might be achieved, for instance, by an alert dialog (see Figure 3.2.4). 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. An example of this might be when an author is publishing a document to their site. In general, we recommend using the less disruptive timing options.

    Screenshot of accessibility alert dialogFigure 3.2.4: Example of a dialog box making an immediate interruption. [d]
    (Source: mockup by AUWG)
  2. Configured 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 are flexible as to whether the author should take immediate action or address the issue at a later stage in the design process. This type of unintrusive alert can be better integrated into the design workflow. For example, a colored outline might be drawn around offending objects in a WYSIWYG view (see Figure 3.2.5), while the markup text for the same object might be highlighted by a different font color in the code view (see Figure 3.2.6). Besides being unintrusive, such indicators will have the added benefit of informing the author about the distribution of errors within the document without interrupting their editing process.Of course, some authors may choose to ignore the alerts completely. In this case, the AUWG does not recommend forcing the author to fix the problem. Instead, it recommends that, at some major editing event (e.g., when publishing), the tool should remind the author of the continuing unresolved accessibility issues.

    Screenshot of code view with font color accessibility highlightingScreenshot of WYSIWYG view with outline highlighting and pop-up men of correction options Figure 3.2.5 (left): Example of highlighting in a WYSIWYG editor. [d]
    (Source: mockup by AUWG)

    Figure 3.2.6 (right): Example of font color highlighting in a code view. [d]
    (Source: mockup by AUWG)
  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, printing, 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 time to make the required changes, especially if they are extensive.

    Screenshot of save as dialog with warning messageFigure 3.2.7: Example of a scheduled prompt included at the bottom of a "save as" dialog. [d] (Source: mockup by AUWG)

Other Techniques:

Reference:

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.

Levels of Automation:

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 judgement may be semi-automated at best. The categories of repair include:

  1. Manual: The tool provides the author with instructions for making the necessary repair, but does not automate the task in any meaningful way (i.e. the tool may move the cursor to start of the problem). As a result, the author must follow the instructions and make the repair by themselves. For example, a tool might flag an img element as missing alt-text, but leave it up to the author to add the appropriate markup and text string (see Figure 3.3.1).

    Screenshot of code view with font color accessibility highlightingFigure 3.3.1: Example of a manual repair in a code view. The tool has detected the problem and selected the offending element, but the user must make the repair. [d]
    (Source: mockup by AUWG)
  2. Semi-Automated: For some types of problems, the tool may be able to help perform the repair, but the author's input is still required. For example, the tool may prompt the user 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 (see Figure 3.3.2).

    Screenshot of WYSIWYG view with outline highlighting and pop-up men of correction options Figure 3.3.2: Example of a semi-automated repair in a WYSIWYG editor. The user has right-clicked on a highlighted object. The user must then decide whether the suggested "alt" text is appropriate. If the user decides that it is, the tool handles the details of updating the markup. [d]
    (Source: mockup by AUWG)
  3. Automated: For some types of problems, tools may be is able to make repairs automatically. For example, in cases where the user wishes to strip out every instance of specific element (see Figure 3.3.3). In these cases, very little, if any, user interface is required.

    Screenshot of a pop-up dialog explaining the blink and marquee elements have been re-styledFigure 3.3.3: Automated repair. Since an automated repair might be completed with the user interface, here is an example of an announcement that might follow an automated repair. [d]
    (Source: mockup by AUWG)

Special-Purpose Correcting Interfaces:

When problems require some human judgement, the simplest solution is often to display the property editing mechanism for the offending element. This has the advantage that the user 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 (see Figure 3.3.4) that includes only the input field(s) for the information currently required. The 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 alt-text 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).

Screenshot of contrived accessibility prompting checkerFigure 3.3.4: Example of special-purpose correction interface. [d]
(Source: mockup by AUWG based on A-Prompt)

Sequential Checking:

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 the 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 the user can complete one at a time. The later steps can then be updated on the fly to take into account the information provided by the user in earlier steps. A checker is a special case of a wizard in which the number of detected errors determines the number of steps. For example, word processors usually have checkers that display all the spelling problems one at a time in a standard template with places for the misspelled word, a list of suggested words, and the correct word. The user also has correcting options, some of which can store responses to affect how the same situation is handled later.

Screenshot of contrived accessibility prompting checkerFigure 3.3.5: Example of a sequential accessibility checker that incorporates the special-purpose correction interface from Figure 3.3.4. [d]
(Source: mockup by AUWG based on A-Prompt)

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 markup-based according to the target audience of the tool), suggesting multiple solutions and choosing between or creating new solutions. In addition, the dialog may include context-sensitive instructive text to help the author with the current correction.

Real-Time (Live) Authoring:

When authoring tools produce content in real-time, the luxury of prompting on a user configurable schedule is to a large degree lost. At the same time, due to the time pressure, authors in real-time environments 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:

Screenshot of contrived whiteboard/chat tool with whiteboard description promptingFigure 3.3.6: Real-time presentation in a Whiteboard/Chat environment. Notice the functionality for requesting
whiteboard descriptions, volunteering to be the secondary author (describer), and describing a whiteboard object even as the dialog continues. [d] (Source: mockup by AUWG).

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:

Other Techniques:

Reference:

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:

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

Note: This checkpoint is priority 3 and is, therefore, not required to be implemented in order for a tool to conform to ATAG 1.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 4.1, ATAG checkpoint 4.2, and ATAG checkpoint 4.3) and improve the usability of the tool.

Techniques:

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

Techniques:

Promote accessibility in help and documentation:

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

Techniques:

ATAG Checkpoint 3.8: Document the process of using the tool to produce accessible content. [Relative Priority]

Techniques:

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