ATAG20 Techniques (for WCAG2.0)

GUIDELINE 3 : Support the author in the production of accessible content

*NEW* 3.1 Assist the author to avoid accessibility problems when they add content or edit markup. [Relative Priority]

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 also helpful to the author.

Prompting Techniques:

In some cases, especially accessible equivalents that require human judgement, avoiding acessibility problems will require that the tool elicit extra information from the author by prompting. However, in ATAG 2.0, prompting does not refer to 'prompts' in the narrow software sense. Instead prompting is used as a verb meaning to urge, suggest and encourage. In addition:

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.

User Configurability

User acceptance of the accessibility features of an authoring tool will most likely depend on the degree to which the new features preserve existing author work patterns. 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 Jan Richards)

Techniques for Prompting for Equivalent Alternatives (Markup tools technique Multimedia tools technique Content tools technique Programming tools technique):

  • Markup tools technique Multimedia tools technique Content tools technique Provide a preview mode that displays alternative content. Although this may quickly give authors a clear understanding of some problems, they should be warned 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.). Other helpful document views include: a "no style sheets" view and a "no images" view. [T0092]
  • Markup tools technique Multimedia tools technique Content tools technique When non-text content changes, alternative equivalent information associated with that content needs to be kept up to date. Prompt the author to ensure that equivalent still covers the functionality of the non-text content. [T0429] @@new category and T####@@ @@new@@

    • Techniques for Drawing Attention to Prompts

    1. Modified Input Field Order: ATAG 2.0 contains ATAG Checkpoint 5.2 does not require that accessibility related controls either obscure or hinder other controls. Instead, the checkpoint emphasizes that these controls should be allotted a screen presence that is appropriate for their importance. For example, some tools have floating properties bars that display input fields appropriate to the currently selected element (see Figure 3.1.2). The relative importance of a property can be communicated to the author in several ways.
      • Reading Order: Without any other forms of organization, most people will read interface items in a "localized" reading order (i.e. in English, French, etc. this is left to right and top to bottom). The higher visibility of items that occur early in the reading order confers higher apparent importance.
      • Grouping: Grouping input fields can change the reading order and the related judgments of importance. For example, the "H" field in the figure below, rises in the reading order due to a strong grouping with the "W" field.
      • Advanced Options: When the properties are explicitly or implicitly grouped into sets of basic and advanced properties, the basic properties will gain apparent importance. For example, in the figure, below, the fact that the "alt" field appears in the default properties, rather than the collapsible portion of the properties bar confers visibility and apparent importance.

      2. Screenshot of maximized and minimized Dreamweaver property dialog for image - including alt-text fieldFigure 3.1.2: Example of a floating properties bar (top: maximized, bottom: minimized). [d]
      (Source: Macromedia Dreamweaver 2.0)
    2. Input Field Highlighting: Visibility of input fields related to accessibility may be further enhanced by visual highlighting. For example, the fields may be distinguished from others using icons (see Figure A-3), color (see Figure A-4), underlining, etc. When these methods are used, it is important to ensure that that they are consistent with the overall look and feel of the authoring tool interface (as per ATAG Checkpoint 5.1). For example, if an authoring tool uses an icon in the shape of a black dot to denote the required field, this convention might be extended so that a red dot is used to denote the accessibility-related fields. An additional consideration is that in order to meet ATAG Checkpoint 7.1, the highlighting must be implemented so that it is available through APIs, allowing an author with disabilities to access the highlighting through assistive devices (MSAA, Java Accessibility API, GNOME accessibility).

      Screenshot of showing colored input field highlightingScreenshot showing icon input field highlightingFigure 3.1.3: Input field highlighting with an iconic reference to a note. d (Source: mockup by Jan Richards)

      Figure 3.1.4: Input field highlighting with colored input field. d (Source: mockup by Jan Richards)
    3. Grouping Related Input Fields: In some cases, several input fields are required to be completed in order to make a single element accessible. Instead of dispersing these prompts over multiple dialog boxes, it may be more effective to draw them together into one group of controls with a visible tab or other method for accessing the group (see Figure A-5). This can have the additional benefit of allowing accessibility-related help information to be provided without confusion (see "Quick Tips" in the figure, below). The downside of placing all the accessibility related input fields in the same area is that all of them will be neglected if the author does not see the grouping.

      Screenshot of HomeSite tag editor for input elementFigure 3.1.5: Accessibility tab on the input element properties dialog. d (Source: mockup by Jan Richards)

    Other Techniques for Providing Assistance:

    Reference:

    Sample(s):

     
    WCAG 2.0 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 2.0 Guideline 2 - Operable. Ensure that the interface elements in the content are operable by any user.
    ?
    WCAG 2.0 Guideline 3 - Navigable. Facilitate content orientation and navigation
    ?
    WCAG 2.0 Guideline 4 - Understandable. Make it as easy as possible to understand the content and controls.
    ?
    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.
    ?

     

     

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

    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 tha author, the tool also helps the author address the issue.

    Levels of Automation:

    Accessiblity 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 meaningul 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).

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

      Figure: 3.2.2: Example of a semi-automated check. [d]
      (Source: mockup by Jan Richards)

    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.

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

    Timing Options for "Informing" the Author:

    Accessiblity 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 acheived, 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 Jan Richards)
    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 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 optionsFigure 3.2.5 (left): Example of inobtrusive highlighting in a WYSIWYG editor. [d]
      (Source: mockup by Jan Richards)

      Figure 3.2.6 (right): Example of font color highlighting in a code view. [d]
      (Source: mockup by Jan Richards)
    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 Jan Richards)

    Other Techniques:

    Reference:

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

    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 Jan Richards)
    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 Jan Richards)
    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: 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 Jan Richards)

    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 Jan Richards 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 Jan Richards 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 Jan Richards).

    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:

    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:

    3.5 Provide functionality for managing, editing, and reusing alternative equivalents for non-text objects. [Priority 3]

    Note: Although this checkpoint is only priority 3, implementing this checkpoint has the potential to simplify the satisfaction of several higher priority checkpoints (Checkpoint 3.1, Checkpoint 3.3).

    Techniques:

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

    Techniques:

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

    Techniques:

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

    Techniques: