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.

Working Draft 17 November 2003

This version:
http://www.w3.org/TR/2003/WD-ATAG20-TECHS-20031031/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:
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.

Guiding the author to produce accessible content:

Promoting accessibility in help and documentation:

Guiding the author to produce accessible content:

Note: This is proposed text.
Conformance with accessibility authoring practices is an authoring constraint, analogous to producing valid code or grammatical text. Since the role of any authoring tools is to facilitate satisfaction of authoring constraints, it is natural that tools should include features to facilitate the process of creating accessible content. The checkpoint requirements for this section include prompting and assisting the author to create accessible content, especially for information that cannot be generated automatically, such as descriptions of graphics (Checkpoint 3.1), checking for accessibility problems (Checkpoint 3.2), and assisting in the repair of accessibility problems (Checkpoint 3.3).

Implementation Note: All functions added to support accessible authoring should be flexible enough to take into account different authoring styles. When authors can configure accessibility features to support their regular work patterns, they will be more likely to feel comfortable with their use and be more receptive to interventions from the tool. For example, some authors may prefer to be alerted to accessibility problems when they occur, whereas others may prefer to perform a check at the end of an editing session.

ATAG Checkpoint 3.1: Prompt and assist the author to create accessible 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, from the user's perspective, the most visible form of assistance will most likely be 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 to maximize the develop a positive disposition and awareness towards accessible authoring practices on the part of authors.

 
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 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. This intervention may proceed according to a user-configurable schedule.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 1.1.X:

 

 

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

 

Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 1.1.Y:

 

Examples of Prompts:

Example 1: Prompting for Short Text Labels (e.g. Alternate text, Titles, Rubies for Ideograms)

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

Promoting accessibility in help and documentation:

Note: This is proposed text.
Because authors are likely to differ widely in their familiarity with Web content accessibility issues, the help and documentation of the authoring tool must address several types of use. The checkpoint requirements for this section include documenting accessible content promoting features (Checkpoint 3.7), ensuring that accessibility solutions are modeled in the documentation and help(Checkpoint 3.8), and including suggested workflow instructions for using the tool to produce accessible content (Checkpoint 3.9).

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

Techniques for Success Criteria 1: All features that play a role in creating accessible content must be documented in the help system.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique 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?".
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.7.3: 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 user interface).
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.7.2: 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 interface (dialog screenshots, etc.) must meet the requirements of WCAG, regardless of whether the examples are intended to demonstrate accessibility authoring practices.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.8.1: In the documentation, ensure that all code examples pass the accessibility vhevking mechanism required for checkpoint 3.1, regardless of what aspect of the code, the example is meant to show.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique 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.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.8.3: When the help files of a base tool do not meet this checkpoint, an accessibility plugins that updateds the files is acceptable.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique 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. @@WCAG Territory - RECOMMEND DELETE@@
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique 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.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.8.7: For tools that include tutorials, provide a tutorial on checking for and correcting Web accessibility problems.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.8.8: Include pointers to more information on accessible Web authoring, such as @@WCAG@@ and other accessibility-related resources,
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique 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] [@@ed. The term "workflow" still needs definition.@@]

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.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.9.1: Document the sequence of steps that the author should take, using the tool, in order to increase the liklihood of producing accessible content. This should take account of any idiosyncrasies of the tool.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.9.2: This documentation could be located in a dedicated section. @@RECOMMEND DELETION@@
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.9.3: The section could be prefaced by an introduction that explains the importance of accessibility for a wide range of users, from those with disabilities to those with alternative viewers.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique Technique 3.9.4: 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.
Techniques for Success Criteria 2: For tools that lack a particular accessibility-related feature, the workflow description must include a workaround for that feature.
Markup tools technique Multimedia tools technique Content tools technique Programming tools technique 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 (3.1) and repair (3.2).
   

 

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