[Contents] [Part A] [Part B] [References]

W3C

Part B: Support the production of accessible content


Notes:


Guideline B.1: Enable the production of accessible content

ATAG Checkpoint B.1.1 Support content types that enable the creation of content that conforms to WCAG. [Priority 1] (Rationale)

Techniques for Success Criterion 1 (Any authoring tool that chooses the content type used for publication on the Web for the author must always choose content types for which a published content type-specific WCAG benchmark document exists.):

Applicability: This success criterion is only applicable to authoring tools that choose the content type for authoring.

Technique B.1.1-1.1 [Sufficient]: Providing a content type-specific WCAG benchmark (referenced in the ATAG 2.0 conformance profile) for all content types that are automatically chosen, either because a content type is the only one that is supported for a given task or because a shortcut is provided that allows new content to be created with a minimum of steps.

Applicable to Indirect authoring functions Example B.1.1-1.1: A content management tool is implemented using HTML templates, Javascript and CSS for both the user interface and author generated content. A content type-specific WCAG benchmark that encompasses these three content-types is therefore published as part of the tool's conformance claim.

Techniques for Success Criterion 2 (Any authoring tool that allows authors to choose the content type used for publication on the Web must always support at least one content type for which a published content type-specific WCAG benchmark document exists and must always give prominence to those content types.):

Applicability: This success criterion is only applicable to authoring tools that let the author choose the content type for authoring.

Technique B.1.1-2.1 [Sufficient]: Providing at least one of the content types that has a content type-specific WCAG benchmark (referenced in the ATAG 2.0 conformance profile) as the first option whenever the author has a choice of content types.

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Example B.1.1-2.1: An authoring tool only claims ATAG 2.0 conformance for plain HTML documents, but allows production of CSS stylesheets, SVG, and MathML. When the author selects "File>New", a dialog box is displayed with the available content types listed with HTML at the top.

Technique B.1.1-2.2 [Advisory]: Displaying a warning when the author chooses to create Web content with a content type that lacks a content type-specific WCAG benchmark (in the ATAG 2.0 conformance profile).

Applicable to Code-Level authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Example B.1.1-2.2: An authoring tool displays a dialog box with a list of content type options. If the author selects a content type that lacks a content type-specific WCAG benchmark (in the ATAG 2.0 conformance profile), a status line displays the following text: "Accessibility support is not available for documents in the format". If the author activates the option, the same warning occurs in a dialog box and the author must indicate "OK" to proceed.

General Techniques for Checkpoint B.1.1:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique B.1.1-General.1 [Advisory]: Consulting content type-specific WCAG benchmark in ATAG 2.0 for guidance on how to create a benchmark document for a content type that does not already have one.

Technique B.1.1-General.2 [Advisory]: Supporting W3C Recommendations, which are reviewed for accessibility, wherever appropriate. References include:

Technique B.1.1-General.3 [Advisory]: For tools that dynamically generate Web content, using HTTP content negotiation to deliver content in the preferred content type of the end-user.

ATAG checkpoint B.1.2 Ensure that the authoring tool preserves accessibility information during transformations and conversions. [Priority 1] (Rationale)

Techniques for Success Criterion 1 (During all transformations and conversions supported by the authoring tool, accessibility information must always be handled according to the following: (a) the accessibility information is available to end users in the result of the transformation or conversion, or (b) if the accessibility information cannot be preserved, notify the author and keep a copy in the original form (e.g., by commenting out a table converted into a list, by saving a document prior to converting it into a different format).):

Applicability: This success criterion is only applicable to authoring tools that perform either transformations or conversions.

Technique B.1.2-1.1 [Sufficient for (a)]: Ensuring that after transformations and conversions, any accessibility information that was stored in the original content is remains present in the resulting content, in such a way that the accessibility information is available to end users (e.g. is rendered, is available to assistive technologies, etc.).

Technique B.1.2-1.2 [Sufficient for (b)]: Ensuring that when a transformation or conversion is to be performed that cannot be performed while preserving accessibility information, the author is warned that accessibility information (if any exists) will be lost and is given the option of allowing the tool to proceed to create the resulting content while saving a backup copy of the original content or preserving the original content markup by canceling the transformations and conversion.

Technique B.1.2-1.3 [Advisory]: Implementing additional supports for transformation and conversion, such as:

Technique B.1.2-1.4 [Advisory]: Notifying the author before changing the content type (including the DTD).

Technique B.1.2-1.5 [Advisory]: Providing the author with explanations of automatic changes made during transformations and conversions.

ATAG checkpoint B.1.3 Ensure that the author is notified before content is automatically removed. [Priority 2] (Rationale)

Techniques for Success Criterion 1 (The authoring tool must provide an option to notify the author before permanently removing content using an automatic process.):

Applicability: This success criterion is only applicable to authoring tools that are capable of automatically removing content.

Technique B.1.3-1.1[Sufficient]: When an automatic process is to be performed that cannot be completed without removing content (even including unrecognized markup), providing the author with the option of allowing the tool to remove the markup and proceed with the operation or preserving the markup by canceling the operation.

Technique B.1.3-1.2 [Advisory]: Providing the author the option to confirm or override removal of content either on a change-by-change basis or as a batch process.

ATAG Checkpoint B.1.4 Ensure that when the authoring tool automatically generates content it conforms to WCAG. [Relative Priority] (Rationale | Note)

Techniques for Success Criterion 1 (All content that is automatically generated by the authoring tool (i.e., not authored "by hand") must conform to WCAG.):

Applicability: This success criterion is only applicable to authoring tools that automatically generate some amount of content, including markup.

Technique B.1.4-1.1 [Sufficient]: Ensuring that any action that the authoring tool takes alone that causes content to be added or modified has the result of not introducing new contraventions of the content type-specific WCAG benchmark. Contravening actions are allowed when they are specifically requested by the author (e.g., they choose to insert a specific element by name from a list) or when the author has failed to properly comply with an information request that would have prevented the contravention (e.g., ignored a short text label prompt for an image).

Technique B.1.4-1.2 [Advisory]: Using prompting to elicit information from the author when necessary (see Checkpoint B.2.1).

Technique B.1.4-1.3 [Advisory]: Ensuring that any mechanisms involved in the automatic generation processes result in content that meet the content type-specific WCAG benchmark (see Checkpoint B.1.5).

ATAG Checkpoint B.1.5 Ensure that all pre-authored content for the authoring tool conforms to WCAG. [Relative Priority] (Rationale | Note)

Techniques for Success Criterion 1 (Any content (e.g., templates, clip art, example pages, graphical widgets) that is bundled with the authoring tool or preferentially licensed to the users of the authoring tool (i.e., provided for free or sold at a discount) must conform to WCAG when used by the author.):

Applicability: This success criterion is not applicable to authoring tools that do not bundle or preferentially license pre-authored content.

Technique B.1.5-1.1 [Sufficient]: Ensuring that any Web content that is bundled with the authoring tool (e.g., on the installation media) or preferentially licensed to the users of the authoring tool (i.e., provided for free or sold at a discount), meets the content type-specific WCAG benchmark.

Technique B.1.5-1.2 [Advisory]: Authoring Web content to be bundled using ATAG 2.0 conformant authoring tools and ensuring it passes accessibility checks.

Technique B.1.5-1.3 [Advisory]: Providing pre-authored graphical content in content types that allow for accessible annotation to be included in the files, such as SMIL [SMIL], PNG [PNG], and SVG [SVG].

Technique B.1.5-1.4 [Advisory]: Ensuring that equivalent alternatives provided for pre-authored content are usable compatible with features to manage, editing, and reusing equivalent alternatives (see Checkpoint B.2.5).

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 B.1.5-1.4: An authoring tool is shipped with a clip art collection. Each image in the collection has a short text label and long text description and the associations have all been pre-loaded into the equivalent alternative management system so that whenever the author inserts an image its equivalent alternatives are automatically retrieved.


Guideline B.2: Support the author in the production of accessible content

ATAG Checkpoint B.2.1 Prompt and assist the author to create content that conforms to WCAG. [Relative Priority] (Rationale)

Implementation Notes:

Techniques for Success Criterion 1 (The authoring tool must provide an option to notify the author when content is added or updated, that requires accessibility information from the author to conform to WCAG (e.g., using a dialog box, using interactive feedback).):

Applicability: This success criterion is applicable to all authoring tools.

Technique B.2.1-1.1 [Sufficient]: Ensuring that, whenever content that requires accessibility information from the author in order to agree with the content type-specific WCAG benchmark is added/updated, the author is informed of the need for the additional information by prompting mechanisms and assisting mechanisms that are appropriate for the type of information in question (see Prompting for Various Types of Accessibility Information).

Technique B.2.1-1.2 [Advisory]: Checking all textual entries for spelling, grammar, and reading level (where applicable).

Technique B.2.1-1.3 [Advisory]: Providing 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:

Applicable to 'what you see is what you get' authoring functionsExample B.2.1-1.3: A WYSIWYG authoring interface includes a list of rendering options as sub-menu options of a View menu. 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). In the background, the "earthrise" image in the WYSIWYG view can be seen in grayscale. (Source: mockup by AUWG)
See the example caption above for description.

Techniques for Success Criterion 2 (Instructions provided to the author by the authoring tool must (if followed) meet one of the following: (a) lead to the creation of content that conforms to WCAG, or (b) inform the author that following the instructions would lead to Web content accessibility problems.):

Applicability: This success criterion is applicable to all authoring tools.

Technique B.2.1-2.1 [Sufficient for (a)]: Remove any instruction text that, if followed exactly by the author, would lead to content being created or modified to disagree with the content type-specific WCAG benchmark.

Technique B.2.1-2.2 [Sufficient for (b)]: Consistently labeling help documents or other documentation that, if followed exactly by the author, would lead to content being created or modified to disagree with the content type-specific WCAG benchmark.

Extended Techniques: Prompting for Various Types of Accessibility Information:

This list is meant to cover techniques of prompting and assisting for many, but not all, of the most common accessible authoring practices:

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

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 (1a): A dialog box offers short text labels for reuse. It shows an "Insert Image" dialog box a thumbnail image of the "earthrise" graphic along with entry fields for src, alt, longdesc, height and width. The alt entry field is drop-down list that is shown with several short labels for the same image. The first is a visual description in English ("An earth rise as seen from the moon"), the second is a visual description in French ("Une vue do la terre de la lune") and the third is an English functional label used if the image serves as a link ("Go to pictures of the earth"). (Source: mockup by AUWG)
See the example caption above for description.

Applicable to Code-Level authoring functions Example (1b): A code-level authoring interface offers short text labels for reuse. It shows the author midway through adding markup for an image. After adding the src attribute value the author has pressed the spacebar, causing the tool to prompt them with the alt attribute along with several attribute values, including a visual description in English (alt="An earth rise as seen from the moon"), a visual description in French (alt="Une vue de la terre de la lune") and an English functional label used if the image serves as a link (alt="Go to pictures of the earth"). (Source: mockup by AUWG)
See the example caption above for description.

(2): Prompting and assisting for multiple text labels (e.g., image map area 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 (2): An authoring interface that prompts for image map area text labels. 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 the text labels (left-hand column). A checkbox at the bottom provides the option of using the text labels to create a set of text links below the image map. (Source: mockup by AUWG)
See the example caption above for description.

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

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): An authoring interface that prompts for long text descriptions. 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. If they choose to use an existing file, there is a text entry area for the name along with a button to browse the file system. If they choose to compose a new description, there is a text entry area for the description followed by a text field for the file name and a button to save it to that location. In the situation shown, the author chooses to use an existing description of "earthrise" so the file name containing the description is shown. In addition, the text of the description from the file is loaded into the compose area ("The earth hangs in the pitch black sky above the gray horizon of the moon. The dazzling blue sphere is covered with creamy white streamers of cloud.") in case the author would like to use this text as a basis for a new description. (Source: mockup by AUWG)
See the example caption above for description.

(4): Prompting and assisting for form control 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 (4): A form properties list with five columns that allows the author to simultaneously decide the following for each field: the tab order, form name, field label, control type, and accesskey. In this example, two form field labels are missing, causing prompts (yellow highlighting of the cells and red icons) to be displayed. "Move up" and "move down" buttons are provided. (Source: mockup by AUWG)
See the example caption above for description.

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

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

Applicable to 'what you see is what you get' authoring functions Example (6): Two views of a "Set TAB Order" utility that lets the author visualize and adjust the TAB order of a document: the first is a mouse-driven graphical overlay on the screen and the second is a keyboard accessible version. In the mouse-driven version, small white-on-red numbers are displayed on the WYSIWYG view, denoting the order. In the keyboard-accessible version, the focusable objects are listed in a list with three columns: position in the TAB order, the control name or label, and the control type. "Move up" and "move down" buttons are provided
See the example caption above for description.

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

Applicable to 'what you see is what you get' authoring functions Example (7a): A WYSIWYG mechanism that detects repeating navigation elements and asks the author whether they want to add a skip navigation link. The WYSIWYG editing view shows the author working on a page that is part of a site called "AstroNet". The page has a navigation bar at the top that includes links to the AstroNet home page, "Mercury", "Venus", "Earth", "Mars" and "Jupiter". The entire navigation bar has been highlighted with a blue box. The author has right-clicked on this box to display a pop-up menu with the following accessibility-related choices: "Repair: Add 'skip over navigation' link", "Skip", "Ignore", "Check Accessibility...", and "Help...". (Source: mockup by AUWG)
See the example caption above for description.

Applicable to Code-Level authoring functions Example (7b): A code-level authoring interface that suggests access key values. The following markup can be seen: "<body><p>Here is one of the most famous photographs taken from the <a href="moon.html" > moon.</a></p><It was taken with a special <a href=camera.html" accesskey="c">camera.</p>". A pop-up menu, centered on the word "moon" suggest accesskey="moon", because "moon" begins with "m", followed by the rest of the alphabet in order. Accesskey="c" is missing, however, since it is already used as an accesskey later in the document (for the "camera" link). (Source: mockup by AUWG)
See the example caption above for description.

(8): Prompting and assisting for contrasting colors:

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 (8): A dialog box for choosing sufficiently contrasting color combinations. The dialog box has two tabs: one for text color and one for background color. A "hide low contrast choices" checkbox has been selected, so the palette of colors has been pre-screened so that sufficient contrast between the text and the current background color is assured. All other colors have been grayed out. (Source: mockup by AUWG)
See the example caption above for description.

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

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 (9): A dialog box for embedding a video and managing the video's alternatives. The tool shows a thumbnail of the video (in this case a nebula) and tabs for each type of text and synchronized alternative: captions, audio descriptions, signed translations and a still image. Each tab displays a red or green icon to indicate whether the alternative is available. In this case, the captioning tab pane is shown and this is split into two sections: embedded captions and external captions (SMIL). Both are marked as "not detected", however for the external captions, the author has the option of browsing their system to find the caption file, or launching an authoring utility to create a new caption file. (Source: mockup by AUWG)
See the example caption above for description.

(10): Prompting and assisting for Metadata:

(11): Prompting and assisting for document structure:

Applicable to 'what you see is what you get' authoring functionsExample (11): A WYSIWYG authoring tool that detects opportunities for enhancing structure and alerts the author. On the left side is the WYSIWYG editing view with the title of the page ("Mars") displayed with a blue underline. The author has brought up a pop-up menu for the title and sees the following options: "Repair: Mark as heading (a sub-menu displays the different levels of header (i.e., h1, h2, etc.)) for the author to choose", "Skip", "Ignore", "Check Accessibility...", and "Help...". On the right, an element inspector makes clear that the title is currently marked up as a paragraph. (Source: mockup by AUWG)
See the example caption above for description.

(12): Prompting and assisting for tabular structure:

Applicable to 'what you see is what you get' authoring functions Example (12): A WYSIWYG authoring tool that prompts the author to decide whether the top row of a table contains the table header cells. The top row of the rendered table is outlined in blue to indicate an accessibility problem. The author has brought up a pop-up menu for one of the cells in the top row and sees the following options: "Repair: Set as header row", "Skip", "Ignore", "Check Accessibility...", and "Help...". (Source: mockup by AUWG)
See the example caption above for description.

(13): Prompting and assisting for style sheets:

Applicable to 'what you see is what you get' authoring functions Example (13): A WYSIWYG authoring tool that indicates to the author that a heading has been misused to indicate emphasis. In the WYSIWYG editing view, some text ("VERY HOT") is rendered large and bold because it has been improperly marked as a heading and it is therefore marked with a blue underline as an accessibility problem. The author has brought up a pop-up menu for the text and sees the following options: "Repair: Mark with style (a sub-menu displays the different styles available (i.e., .bodytext, .quotetext, .hot_emphasis, .cold_emphasis))", "Skip", "Ignore", "Check Accessibility...", and "Help...". (Source: mockup by AUWG).
See the example caption above for description.

(14): Prompting and assisting for clearly written text:

Applicable to Code-Level authoring functions Example (14a): A code-level authoring interface that indicates the reading level of a page and whether it exceeds a limit determined by the author's preference settings. The code view includes the following markup: <body><h1>Mars</h1><p>Mars is the fourth planet in the solar system, orbiting at a distance of 1.5 AU, with a period of 687 days.</p></body></html>. Then in a status bar below the text entry area, is a reading level display: "Reading Level: 11.2 (target<8)". The 11.2 is highlighted with a yellow background and bold text to indicate that the target is exceeded. (Source: mockup by AUWG)
See the example caption above for description.

Applicable to 'what you see is what you get' authoring functionsExample (14b): An authoring interface that prompts the author to enter an acronym expansion. The rendered text reads: "The 'habitable zone' around a star is the region of that star’s solar system in which liquid water is possible. The continuous habitable zone (CHZ) is the region of the solar system which has remained in the zone, even during changes in the star’s radiation pattern." The acronym "CHZ" is identified with a blue underline as an accessibility problem. The author has brought up a pop-up menu for the acronym and sees the following options: "Repair: Enter acronym expansion…", "Check Accessibility...", and "Help...". (Source: mockup by AUWG)
See the example caption above for description.

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

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

Applicable to 'what you see is what you get' authoring functions Example (16): An authoring interface for prompting the author about whether a paragraph that contains many numbers might be made more clear with the addition of a chart or graph. On the left side of the interface is the rendered text: " Planet Orbits: The inner planets orbit the sun relatively quickly with Mercury orbiting the sun in 88 days, Venus in 224 days, Earth in 365 days, and Mars in 687 days. Compare this to Jupiter’s, 4332 day orbit." This text is marked with a yellow exclamation mark icon. On the right side is the following explanation of the error icon: "This paragraph contains 5 numbers. Would readers benefit if a chart or graph of this information was added?". "Yes" and "no" buttons are provided. (Source: mockup by AUWG)
See the example caption above for description.

(17): Prompting and assisting the author to make use of up-to-date content types:

ATAG Checkpoint B.2.2: Check for and inform the author of accessibility problems. [Relative Priority] (Rationale | Note)

Implementation Notes:

Techniques for Success Criterion 1 (An individual check must be associated with each requirement in the content type-specific WCAG benchmark document (i.e., not blanket statements such as "does the content meet all the requirements").):

Applicability: This success criterion is applicable to authoring tools that are capable of introducing accessibility problems (i.e., not tools that constrain author actions to the point where accessibility problems are not possible).

Technique B.2.2-1.1 [Sufficient]: Providing at least one check for check for each requirement in the content type benchmark document (see Levels of Checking Automation).

Techniques for Success Criterion 2 (For checks that are associated with a type of element (e.g., img), each element instance must be individually identified as potential accessibility problems. For checks that are relevant across multiple elements (e.g., consistent navigation) or apply to most or all elements (e.g., background color contrast, reading level), the entire span of elements must be identified as potential accessibility problems, up to the entire content if applicable.):

Applicability: This success criterion is applicable to authoring tools that are capable of introducing accessibility problems (i.e., not tools that constrain author actions to the point where accessibility problems are not possible).

Technique B.2.2-2.1 [Sufficient]: Identifying the entire span of elements covered by a potential accessibility problem.

Applicable to Code-Level authoring functions Example B.2.2-2.1(a): A code-level authoring tool displays errors in a separate pane by the line number of the first element in the span.

Applicable to Code-Level authoring functions Example B.2.2-2.1(b): A code-level authoring tool displays errors in-line by underlining all of the markup for the affected span of elements.

Applicable to 'what you see is what you get' authoring functions Example B.2.2-2.1(c): A WYSIWYG authoring tool displays errors in-line with the rendered content in the WYSIWYG editing view as blue outlining around or under the affected span of elements.

Technique B.2.2-2.2 [Advisory]: Displaying manual checks in a way that balances the need for the author to make specific changes to some kinds of content (e.g., non-text objects, acronyms, table cells, etc.) while not overwhelming the author with numerous manual checks for other kinds of content that can be checked more generally (e.g., background color contrast, reading level, etc.).

Techniques for Success Criterion 3 (If the authoring tool relies on author judgment to determine if a potential accessibility problem is correctly identified, then the message to the author must be tailored to that potential accessibility problem (i.e., to that requirement in the context of that element or span of elements).):

Applicability: This success criterion is applicable to authoring tools that are capable of introducing accessibility problems (i.e., not tools that constrain author actions to the point where accessibility problems are not possible).

Technique B.2.2-3.1 [Sufficient]: The wording of author information prompts during checking for a potential problem supports author judgment by answering the following questions: "What part of the content should be examined?" and "What is present or absent in the event that the problem exists?".

Example B.2.2-3.1: @@A checking utility demonstrates... @@

Techniques for Success Criterion 4 (The authoring tool must present checking as an option to the author at or before the completion of authoring.):

Applicability: This success criterion is applicable to authoring tools that are capable of introducing accessibility problems (i.e., not tools that constrain author actions to the point where accessibility problems are not possible).

Technique B.2.2-4.1 [Sufficient]: Providing accessibility checking as an action (e.g., as a menu item, etc.) at all times.

Technique B.2.2-4.2 [Sufficient]: If accessibility checking is not always available as an action, prompting the author to perform an accessibility check if the author chooses to close or publish the content.

General Techniques for Checkpoint B.2.2:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique B.2.2-General.1 [Advisory]: Automating as much checking as possible. Where necessary provide semi-automated checking. Where neither of these options is reliable, provide manual checking (see Levels of Checking Automation).

Technique B.2.2-General.2 [Advisory]: Consulting the Techniques for Accessibility Evaluation and Repair Tools [WAI-ER @@change to AERT@@] Public Working Draft for evaluation and repair algorithms related to WCAG 1.0.

Technique B.2.2-General.3 [Advisory]: For certain types of programmatic content, enabling checking by rendering or executing the content as part of the checking process. This may apply to manual as well as automated or semi-automated checking processes.

Technique B.2.2-General.4 [Advisory]: For tools that allow authors to create their own templates, advising the author that templates should be held to a high accessibility standard, since they will be repeatedly reused. Enhancing this by making an accessibility checks mandatory before saving templates (see Checkpoint B.2.2).

Extended Techniques: Levels of Checking Automation:

This list is representative, but not complete.

(a) Automated Checking: 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 of Automated Checking (1): A summary interface for a code-based authoring tool that displays the results of an automated check. The display is a tree-view where the leftmost nodes are the names of errors ("Image missing alternate text" and "Text boxes missing labels) with number of errors appended (e.g., "[6]") and the sub-items are the problem instances with line numbers appended (e.g., "(Line:45)"). (Source: mockup by AUWG)
See the example caption above for description.

Applicable to 'what you see is what you get' authoring functions Example of Automated Checking (2): A WYSIWYG interface that displays the results of an automated check in a WYSIWYG authoring view using blue highlighting around or under rendered elements (in this case, the "earthrise" image and some "blinking text"), identifying accessibility problems for the author to correct. (Source: mockup by AUWG)
See the example caption above for description.

Applicable to Code-Level authoring functions Example of Automated Checking (3): An authoring interface of an automated check in a code-level authoring view. The text is: "<body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>".In this view, the text of elements with accessibility problems (img and blink) is shown in a blue font, instead of the default black font. (Source: mockup by AUWG)
See the example caption above for description.

(b) Semi-Automated Checking: 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 of Semi-Automated Checking: 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 ("Does this image require descriptive text?"). The author can confirm the at this is indeed an accessibility problem by choosing and move on to the repair stage by choosing "Yes" or press "No" to mark the potential problem, as not a problem at all. Additional help is available in the form of a tip: "An image requires descriptive text when the information it contains cannot be conveyed in 10 words or less using an alternate text label." (Source: mockup by AUWG)
See the example caption above for description.

(c) Manual Checking: 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 of Manual Checking: A dialog box that reminds the author to check if there are any words in other languages in the document with the message: "Does this document contain any words or phrases in a different language than the main content?". The author can move on to the repair stage by pressing "Yes" or press "No" to mark the potential problem, as not a problem at all. (Source: mockup by AUWG)
See the example caption above for description.

ATAG Checkpoint B.2.3: Assist authors in repairing accessibility problems. [Relative Priority] (Rationale | Note)

Implementation Notes:

Techniques for Success Criterion 1 (For each potential accessibility problem identified by the checking function (required in Checkpoint B.2.2), at least one of the following must be provided: (a) repair instructions, for the author to follow, that are specific to the accessibility problem or (b) an automated repair or semi-automated repair mechanism.):

Applicability: This success criterion is applicable to authoring tools that are capable of introducing accessibility problems (i.e., not tools that constrain author actions to the point where accessibility problems are not possible).

Technique B.2.3-1.1 [Sufficient]: For each potential accessibility problem identified by the checking function (required in Checkpoint B.2.2), providing repair instructions that an author (with sufficient skill and knowledge to use the rest of the tool) could follow to correct the problem. At the developer's discretion, semi-automated repairs (that prompts the author for required information) or automated repairs (that are able to complete the repair without prompting the author) may be substituted.

Technique B.2.3-1.2 [Advisory]: Automating as much repairing as possible. Where necessary provide semi-automated repairing (see Levels of Repair Automation). Where neither of these options is reliable, provide manual repairing.

Technique B.2.3-1.3 [Advisory]: Implementing a special-purpose correcting interface where appropriate. 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 B.2.5).

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 B.2.3-1.3: A special-purpose correction interface. The tool supports the author's repair task by providing (1) a short description of the problem (here: "Missing Alternate Text Label for an Image"), (2) a preview (here: the "earthrise" image that is missing a label), (3) tips for performing the repair (here: "Alternate text should be 10 words or less and should include any text in the image."; "Image buttons should have alternate text that describes the button function."; and "Image bullets should have "bullet" as alternate text."), and (4) an offered semi-automated repair in an editable drop-down box (here: "An earth rise as seen from the moon"). (Source: mockup by AUWG)
See the example caption above for description.

Technique B.2.3-1.4 [Advisory]: Sequencing checks. 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 that performs checks in an order that is apparent to the author. 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 B.2.3-1.4: A sequential accessibility checker. The special-purpose correction interface from Example B.2.3-1.3 is supplemented a progress indicator ("5 of 25") and with navigation buttons to move backwards ("back") and forwards ("skip") through the list of repair tasks. Buttons to "repair", get "help" and "cancel" are also provided. (Source: mockup by AUWG)
See the example caption above for description.

Technique B.2.3-1.5 [Advisory]: Where an authoring tool is able to detect site-wide errors, allowing the author to make site-wide corrections. This should not be used for equivalent alternatives when the function is not known with certainty (see Checkpoint B.2.4).

Technique B.2.3-1.6 [Advisory]: Providing a mechanism for authors to navigate sequentially among uncorrected accessibility errors. This allows the author to quickly scan accessibility problems in context.

Technique B.2.3-1.7 [Advisory]: Consulting the Techniques for Accessibility Evaluation and Repair Tools [WAI-ER @@change to AERT@@] Public Working Draft document for evaluation and repair algorithms.

Extended Techniques: Levels of Repair Automation:

This list is representative, but not complete.

(a) Repair Instructions: 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 human error.

Applicable to Code-Level authoring functions Example of repair instructions (1): Repair instructions in a code level editing view. In this case, the following markup is being edited: <body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking text</blink></body></html>. Since the problems have already been detected in the checking step and the selected offending elements in a code view (<img href="pic123.gif"/> and <blink>Blinking text</blink>) have been highlighted in blue text. When the author puts focus on the highlighted text, a short repair instruction ("Repair: Add 'alt' attribute") appears in a status bar with a button than will open a longer explanation in the help system. (Source: mockup by AUWG)
See the example caption above for description.

(b) 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 of 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 of semi-automated repair (1): A semi-automated repair in a WYSIWYG editing view. The author has right-clicked on an image of the "earthrise" that has been highlighted with a blue outline by the automated checker system. This has brought up a pop up menu with the following choices: "Repair: Set Alt -Text: 'An earth rise as seen from the moon'", "Enter different alt-text…", " Skip", "Ignore", "Check Accessibility...", "Help...". The author must 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)
See the example caption above for description.

(c) Automated: In automated repairing, 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, author notification is required. This type of repair is usually appropriate for corrections of a syntactic or repetitive nature.

Applicable to Code-Level authoring functions Example of automated repairing (1): An announcement that an automated repair has been completed ("All instances of <blink> have been replaced with CSS styling according to your preferences."). The author selects an "ok" to proceed. An "undo" button is provided in case the author wishes to reverse the operation. In some cases, automated repairs might be completed with no author notification at all. (Source: mockup by AUWG)
See the example caption above for description.

ATAG Checkpoint B.2.4: Assist authors to ensure that equivalent alternatives for non-text objects are accurate and fit the context. [Priority 1] (Rationale)

Techniques for Success Criterion 1 (If the authoring tool offers text alternatives for non-text objects, then the source of the alternatives for each object must be at least one of the following: (a) text alternatives previously entered by authors for the non-text object (e.g., by the same author, or another author on a collaborative system), (b) text alternatives stored with the non-text object in an image database (or equivalent), or (c) null text alternatives for non-text objects that are only used only for visual formatting.):

Applicability: This success criterion is applicable to authoring tools that support non-text objects.

Technique B.2.4-1.1 [Sufficient for (a)]: Placing, within the appropriate field of the non-text object editing dialog box, a text alternative (or multiple alternatives if a drop-down is used) that was previously entered by themselves or by other authors with whom they collaborate (e.g. in a workgroup).

Technique B.2.4-1.2 [Sufficient for (b)]: Placing, within the appropriate field of the non-text object editing dialog box, a text alternative (or multiple alternatives if a drop-down is used) that is stored with the non-text object in an image database such as a clip art collection.

Technique B.2.4-1.3 [Sufficient for (c)]: Placing, within the appropriate field of the non-text object editing dialog box, a null text alternative if the tool is making use of the image only for visual formatting.

Technique B.2.4-1.4 [Sufficient]: Not offering the author text alternatives for non-text objects at all. Leaving out the relevant markup for the alternative equivalent (e.g., attribute, element, etc.), rather than including the attribute with no value or with automatically-generated content if the author has not specified an alternative equivalent. Leaving out the markup will increase the probability that the problem will be detected by checking algorithms.

Techniques for Success Criterion 2 (The authoring tool must allow the author to accept, modify, or reject equivalent alternatives):

Applicability: This success criterion is applicable to authoring tools that support non-text objects.

Technique B.2.4-2.1 [Sufficient]: If human-authored equivalent alternatives are available for an object that is being inserted (through a management functionality (see Checkpoint B.2.5) or equivalent alternatives bundled with pre-authored content (see Checkpoint B.1.5)), then offering the alternatives to the author as default text, requiring confirmation. Inserting the alternatives without author confirmation is not required when the function of the object is known with certainty as in the following situations: (a) the tool totally controls its use (e.g., a button graphic on a generated tool bar); (b) 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; or (c) there is semantic role information stored for the object that matches that for the stored alternative.

Technique B.2.4-2.2 [Advisory]: If the author changes the alternative equivalent for a non-text object, asking the author whether all instances of the object with the same known function should also be updated.

ATAG Checkpoint B.2.5: Provide functionality for managing, editing, and reusing equivalent alternatives. [Priority 3] (Rationale)

Techniques for Success Criterion 1 (The authoring tool must have the option of storing for future re-use the following author added equivalent alternatives for non-text objects (if applicable): (a) plain text text alternatives that the authoring tool stores directly (e.g., alternative text labels, long text descriptions), and (b) URI referenced synchronized alternatives or accessible multimedia alternatives that the authoring tool stores only indirectly (i.e., as URIs to external resources) (e.g., captions for video, sign language interpretation videos).):

Applicability: This success criterion is applicable to authoring tools that support non-text objects.

Technique B.2.5-1.1 [Sufficient]: Maintaining a registry that associates object identity information with the text and URIs of alternative information (e.g., making use of the Resource Description Framework (RDF) [RDF10]). Whenever an object is used and an equivalent alternative is collected, via prompting (see Checkpoint B.2.1) or repair (see Checkpoint B.2.3) the object's identifying information and the alternative information is added to the registry. The stored alternative information is presented back to the author as default text in the appropriate field, whenever the associated object is inserted (see also Checkpoint B.2.4).

Technique B.2.5-1.2 [Advisory]: Providing an entry editing capability. (see Example B.2.5-1.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 Example B.2.5-1.2: A text equivalents registry viewer that allows 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. In the viewer shown here, the author has selected "image" as the "media type" and then selected pic123.gif as the "object" to edit. This has brought up a rendering of the "earthrise" image. The viewer also shows that the object has three text labels. The author has selected one ("An earth rise as seen from the moon") in order to edit it. In addition some authoring tips are included ("Alternate text should be 10 words or less and should include any text in the image", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have "bullet" as alternate text."(Source: mockup by AUWG)
See the example caption above for description.

Technique B.2.5-1.3 [Advisory]: Allowing several different versions of alternative information to be associated with a single object.

Technique B.2.5-1.4 [Advisory]: Ensuring that the stored alternative information required for pre-authored content (see Checkpoint B.1.5) is made interoperable with the management system to allow the alternative equivalents to be retrieved whenever the pre-authored content is inserted.

Technique B.2.5-1.5 [Advisory]: Using the stored alternatives to support keyword searches of the object database (to simplify the task of finding relevant images, sound files, etc.).

Technique B.2.5-1.6 [Advisory]: Allowing the equivalents alternatives registry to be made shareable between authors in collaborative systems.

ATAG Checkpoint B.2.6: Provide the author with a summary of accessibility status. [Priority 3] (Rationale)

Techniques for Success Criterion 1 (The authoring tool must provide an option to view a list of all known accessibility problems (i.e., detected by automated checking or identified by the author) prior to completion of authoring.):

Applicability: This success criterion is applicable to authoring tools that are capable of introducing accessibility problems (i.e., not tools that constrain author actions to the point where accessibility problems are not possible).

Technique B.2.6-1.1 [Sufficient]: Providing, at all times, the option to view a single consolidated list of all of the accessibility problems that are detected by the checking function (see Checkpoint B.2.2), organized by problem type and number of instances.

Technique B.2.6-1.2 [Advisory]: Storing accessibility status information in an interoperable form (e.g., using Evaluation and Repair Language [EARL]).

Technique B.2.6-1.3 [Advisory]: Providing direct links to additional help and repair assistance from the list of accessibility problems.

ATAG Checkpoint B.2.7: Provide the author with a tutorial on the process of accessible authoring. [Priority 3] (Rationale)

Techniques for Success Criterion 1 (The authoring tool must provide a tutorial on the accessible authoring process that is specific to the tool.):

Applicability: This success criterion is applicable to all authoring tools.

Technique B.2.7-1.1 [Sufficient]: Providing a tutorial that contains a method for using the authoring tool to increase the accessibility of Web content. The tutorial begins at the typical starting point for the tool (e.g., empty document) and describes how accessibility prompting and assistance can be used as content is being added or modified. The tutorial also covers when and how checking and repair should be performed.

Technique B.2.7-1.2 [Advisory]: Ensuring that wherever rationales appear, the text avoids referring to accessibility features as being exclusively for particular groups (e.g., "for blind authors"). Instead, the rationales emphasize the importance of accessibility for a wide range of content consumers, from those with disabilities to those with alternative viewers (see "Auxiliary Benefits of Accessibility Features", a W3C-WAI resource).

Technique B.2.7-1.3 [Advisory]: Providing a dedicated accessibility section.

Technique B.2.7-1.4 [Advisory]: Providing context-sensitive help definitions for accessibility-related terms.

Technique B.2.7-1.5 [Advisory]: Including pointers to more information on accessible Web authoring, such as WCAG and other accessibility-related resources.

Technique B.2.7-1.6 [Advisory]: Including pointers to relevant content type specifications. This is particularly relevant for languages that are easily hand-edited, such as most XML languages.

Technique B.2.7-1.7 [Advisory]: Calling author attention to accessibility-related idiosyncrasies of the tool compared to other authoring tools that create the same kind of content (e.g., that content must be saved before an automatic accessibility check becomes active).


Guideline B.3: Promote and integrate accessibility solutions

This guideline requires that authoring tools must promote accessible authoring practices within the tool as well as smoothly integrate any functions added to meet the other requirements in this document.

Note: In addition to the normative requirements of this guideline, implementers should consider one other issue: the integration of features that support accessible authoring with the "look-and-feel" of other features of the authoring tool. This type of integration has the potential to:

However, whenever new features are introduced into an authoring tool, striking the right design balance between the similarity with existing features and the provision of new functionality is often more of an art than a science.

ATAG Checkpoint B.3.1: Ensure that the most accessible option for an authoring task is given priority. [Priority 2] (Rationale)

Techniques for Success Criterion 1 (When the author has more than one authoring option for a given task (e.g., emphasizing text using semantic markup rather than inappropriately using header markup), then any options that conform to WCAG must have equal or higher prominence than any options that do not.):

Applicability: This success criterion is not applicable to authoring tools that have only one method for performing each task.

Technique B.3.1-1.1 [Sufficient]: Ensuring that, if there are two or more authoring options for performing the same authoring task (e.g., setting color, inserting multimedia, etc.) and one option results in content that agrees with the relevant content type-specific WCAG benchmark while the other does not, the more accessible option is given authoring interface prominence.

Applicable to 'what you see is what you get' authoring functions Example B.3.1-1.1: An authoring tool that supports two methods for setting text color: using CSS and using font. Since using CSS is the more accessible option, it is given a higher prominence within the authoring interface by: (1) the "CSS Styling" option appearing above the "FONT Styling" option in the drop down Text menu, and (2) the CSS styling option being used to implement the one-click text color formatting button in the tool bar. The association is made clear because the toolbar button has the same icon (an "A" beside a color spectrum) as the "Color" sub-menu item under the "CSS Styling" menu option.). An (Source: mockup by AUWG)
See the example caption above for description.

Technique B.3.1-1.2 [Sufficient]: Completely removing less accessible options simplifies the task of meeting this success criterion.

Techniques for Success Criterion 2 (Any choices of content types or authoring option presented to the author (e.g., in menus, toolbars or dialogs) that will lead to the creation of content that does not conforms to WCAG must be marked or labeled so that the author is aware of the consequences prior to making the choice.):

Applicability: This success criterion is not applicable to authoring tools that do not provide choices that will lead directly to accessibility problems.

Technique B.3.1-2.1 [Sufficient]: Ensuring that, when an option will lead directly to content being created using a content type for which there is not a content type-specific WCAG benchmark or content that does not agree with the relevant content type-specific WCAG benchmark, the author is warned (e.g., be a warning message, by an informational icon, etc.).

Technique B.3.1-2.2 [Sufficient]: Completely removing choices that will lead directly to content being created using a content type for which there is not a content type-specific WCAG benchmark or content that does not agree with the relevant content type-specific WCAG benchmark simplifies the task of meeting this success criterion.

ATAG Checkpoint B.3.2: Ensure that sequential authoring processes integrate accessible authoring practices. [Priority 2] (Rationale)

Techniques for Success Criterion 1 (Interactive features that sequence author actions (e.g., object insertion dialogs, templates, wizards) must provide any accessibility prompts relevant to the content being authored at or before the first opportunity to successfully complete the interactive feature.):

Applicability: This success criterion is not applicable to authoring tools that do not provide interactive features that help sequence author actions (e.g., many basic text editors).

Technique B.3.2-1.1 [Sufficient]: Ensuring that any feature that sequences authoring actions (by allowing different defined sets of actions at different points in a process) integrates accessibility prompting in such a way that there is no opportunity to finalize an authoring decision before prompting related to the accessibility implications of that decision.

Applicable to Indirect authoring functions Example B.3.2-1.1: Three consecutive screens of a page building wizard (an example of indirect authoring). The wizard prompts the author for a few key pieces of information that are used to tailor the process, in this case to create a gallery page. In the first step, the author is prompted for a title ("Space Pictures"), a page type ("Gallery") and a style ("SciFi"). The only available navigation button is "Next >". In the second step, the author is prompted to add the first image. The available navigation buttons are now "< Previous" and "Next >". In the third step, the author is prompted for accessibility information ("label" and "description" for the image ("earthrise") which is displayed as a rendered preview). This is the first step in which the "Finish" navigation button becomes available. (Source: mockup by AUWG)
See the example caption above for description.

Technique B.3.2-1.2 [Advisory]: Integrate checking and repairing into sequencing mechanisms (e.g., design aids, wizards, templates).

Applicable to Indirect authoring functions Example B.3.2-1.2: A wizard screen that immediately follows the sequence in Example B.3.2-1.1. Since no text was entered in the description field, a warning message is displayed ("Missing Description for 'Gallery Image 1'" along with a space to add a description and a preview rendering of the image ("earthrise"). (Source: mockup by AUWG)
See the example caption above for description.

Technique B.3.2-1.3 [Advisory]: Choosing timing options that prompt early in the workflow (see Timing Options). This averts the need for more disruptive checking and repair later in the workflow.

Technique B.3.2-1.4 [Advisory]: Detecting and immediately highlighting accessibility problems when documents are opened, when an editing or insertion action is completed, or while an author is editing.

Technique B.3.2-1.5 [Advisory]: If intrusive warnings are used, providing the option to select a less obtrusive method of alerting.

Technique B.3.2-1.6 [Advisory]: Providing the author with immediate access to some basic accessibility documentation and one-step access to more comprehensive documentation.

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 B.3.2-1.6: An accessibility checker with some limited short label authoring tips listed beneath the text entry area as well as a "Help" button linking to the full documentation. The tips are: "Alternate text should be 10 words or less and should include any text in the image.", "Image buttons should have alternate text that describes the button function.", and "Image bullets should have 'bullet' as alternate text.". The screenshot also includes the name of the problem ("Missing Alternate Text Label for an Image"), a field for adding the short text label and a preview rendering of the image ("earthrise"). At the bottom are five buttons: "Help", "< Back", "Repair", "Skip", and "Cancel". (Source: mockup by AUWG)
See the example caption above for description.

Technique B.3.2-1.7 [Advisory]: Providing a tight coupling between all of the accessibility-related functions, leading to a more seamless authoring experience.

Applicable to 'what you see is what you get' authoring functions Example B.3.2-1.7: A sequence of steps through a WYSIWYG user interface in which prompting, checking, repair, and documentation of accessibility issues are all integrated into the process of creating a table. In the first step, the author has requested that a table be inserted. The tool prompts the author for accessibility information (i.e., caption and summary) at the same time as it prompts for the number of rows, number of columns, border and width. In the second step, as the author finishes filling in the top row of cells, the tool has checked the structure of the table and found that no header cells have been defined. To prompt the author to address this problem, the tool highlights the top row of the table in a blue outline. When the author selects the highlighted area a drop-down is displayed that lets the user choose whether to let the tool make the repair ("Repair: Set as header row"), skip the problem for now ("Skip") or ignore the problem from here on ("ignore"). The last options are "Check Accessibility" to open a full checker and "Help". In the third step, the author has added a new row to the top of the table and merged two cells in this new top row. The tool again checks the table, highlights the problem and facilitates the repair ("Repair: Set as header cell for sub-headers"). (Source: mockup by AUWG)
See the example caption above for description.

Extended Techniques: Real-Time Content Production

Dealing flexibly with real-time content production. When authoring tools produce content in real time, it is usually no longer possible to delay addressing accessibility problems until an 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 should still take accessibility issues into account by supporting the following:

(a) 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, a 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 (e.g., using CCPP, ACCLIP) to determine which types of accessibility practices would offer the greatest advantage in 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.

(b) 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).

(c) 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.

(d) 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:

Applicable to 'what you see is what you get' authoring functions Example B.3.2-1.4: A real-time presentation in a whiteboard/chat client environment that has been enhanced to provide real-time descriptions. The example has five panes. On the far left is a list of participants ("Presenter", "John (You)", "Jane", and "Alice"). In the upper-middle is the chat "Presenter> I suggest a space theme for the slide presentation.", "Image File Inserted (by Presenter) Description: An earthrise as seen from the surface of the moon.", "Presenter> The white text would go...", "Marker (by Presenter) Description> Draws a red box..., and "Presenter> in this area." Notice that descriptions are appearing here. The lower-middle is the message composition area for this user and is blank. The upper-right is the whiteboard. So far there is an image of "earthrise" and a red hand-drawn rectangle on the "canvas". The whiteboard tools are "select box", "text tool", "marker", "eraser", "insert image", "line tool", "rectangle tool", and an "ellipse tool". In the lower-right is an area for describing a drawing action - in this case the "Presenter' use of the Marker". Notice that any participant can describe the events on the whiteboard even as the dialog continues. (Source: mockup by AUWG).
See the example caption above for description.

Techniques for Success Criterion 2 (For read-only instruction text (e.g., tutorials, reference manuals, design guides) that includes a sequence of steps for the author to follow, the relevant accessibility authoring practices must appear in the step sequence before the first opportunity to successfully complete the sequence.):

Applicability: This success criterion is not applicable to authoring tools that do not provide read-only instruction text that includes a sequence of steps for the author to follow.

Technique B.3.2-2.1 [Sufficient]: Ensuring that in any set of instruction steps, the first point at which the author could successfully complete the action (and introduce an accessibility problem) is after the point at which the relevant accessibility authoring practice has been introduced.

Extended Techniques: Author Interruption Timing Options

This list is representative, but not complete.

(a) Negotiated Interruption: A negotiated interruption is caused by interface mechanisms (e.g., icons or highlighting of the element, audio feedback) 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 or scheduled interruptions, they can often be better integrated into the design workflow and have the added benefit of informing the author about the distribution of problems within the document. Although some authors may choose to ignore the alerts completely, it is not recommended that authors be forced to fix problems as they occur. Instead, it is recommended that negotiated interruption be supplemented by scheduled interruptions at major editing events (e.g., when publishing), when the tool should alert the author to the outstanding accessibility problems.

Applicable to 'what you see is what you get' authoring functions Applicable to Code-Level authoring functions Applicable to Object-Oriented authoring functions Example of negotiated interruption: A WYSIWYG editing view makes the author of problems detected automatically by means of a blue line under text or around rendered objects with accessibility problems. Here, red lines are also visible, highlighting spelling errors in the text. The author can decide to address the problems at a later time. (Source: mockup by AUWG)
See the example caption above for description.

(b) 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 opening, saving, closing, committing, or publishing files. 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. A potential downside of postponing corrective actions is that by the time the prompt is displayed, the author may not have sufficient time or inclination 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 of scheduled interruption: A "Publish" dialog box allows the author to publish multiple files at once, however in the case shown here, two of the files have uncorrected accessibility errors which causes them not to meet a "standard of publishing" the author has set for themselves in the options. As a result the files are selected, a message is displayed ("The selected files do not meet your specified standard for publishing.") and the "publishing" button is grayed out. This standard is referred to generally since it is assumed that it might include spelling and grammar standards as well as accessibility issues. (Source: mockup by AUWG)
See the example caption above for description.

(c) 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, negotiated and scheduled interruptions are preferred.

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 of immediate interruption: A modal dialog box contains the message: "This image is missing alternate text". The author must press the "OK" button to continue. (Source: mockup by AUWG)
See the example caption above for description.

ATAG Checkpoint B.3.3: Ensure that features of the authoring tool that support the production of accessible content are prominent in the user interface. [Priority 2] (Rationale)

Rationale: If the features that support accessible authoring are difficult to find and activate, they are less likely to be used. Ideally, these features should be turned on by default.

Techniques for Success Criterion 1 (All accessible content support features must match or exceed the prominence of any corresponding features related to other classes of Web content problems (e.g., markup validity, program code syntax, spelling and grammar)):

Applicability: This success criterion is applicable to authoring tools that provide accessibility prompting, checking, repair functions, or documentation.

Sufficiency: Technique B.3.3-1.1, Technique B.3.3-1.2, and Technique B.3.3-1.3, in combination, are sufficient to meet this checkpoint.

Technique B.3.3-1.1 [Sufficient in combination]: Ensuring that prompting for accessibility information has the same prominence as prompting for information critical to content correctness (e.g., a tool that prompts the author for a required multimedia file name attribute has prompts with the same prominence for short text labels and long descriptions for that object (see Example B.3.3-1.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 Example B.3.3-1.1: An "Image Properties" dialog box in which the input fields are ordered (from top to bottom, left to right): source ("src"), short label ("alt"), long description ("longdesc"), height, and width. The buttons at the bottom are "More...", "OK" and "Cancel". (Source: mockup by AUWG)
See the example caption above for description.

Technique B.3.3-1.2 [Sufficient in combination]: Ensuring that utilities for checking and repairing accessibility problems has the same prominence as utilities for checking for information critical to content correctness (e.g., a tool that checks for spelling, grammar, or code syntax will have checks with the same prominence as checking for accessibility problems (see Example B.3.3-1.2)).

Applicable to 'what you see is what you get' authoring functions Applicable to 'what you see is what you get' authoring functions Applicable to Object-Oriented authoring functions Example B.3.3-1.2: An authoring interface that checks for and displays spelling and accessibility errors with the same prominence in that both are shown as underlines, one red, one blue. In this case, the author has activated a right-click pop-up menu on the word "CHZ" that includes spelling repair options ("1 Khz", "2 Chi", "Check Spelling...") and accessibility repair options ("Repair: Set acronym expansion…", "Skip", "Ignore", and "Check Accessibility...") and "Help...". (Source: mockup by AUWG)
See the example caption above for description.

Technique B.3.3-1.3 [Sufficient in combination]: Ensuring that documentation for accessibility has the same prominence as documentation for information critical to content correctness. (e.g., a tool that documents any aspect of its operation will have documentation with the same prominence for 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 Example B.3.3-1.3: Accessibility documentation is part of the main documentation of an authoring tool, with very similar prominence to that of the spelling-related features. In the right pane is the documentation table of contents, where "Accessibility Features" appears as a top level topic just below "Spelling Features". In the left panel is the help text, demonstrating a style typical of the rest of the help system: "Checking for Accessibility: A variety of accessibility checking options are available: Accessibility verifier, Check accessibility as you type, Manual test support materials. These are suitable for use at different times during the authoring process and all have options that can be changed with the accessibility preferences. To get more information on accessible Web content, see the References.". (Source: mockup by AUWG)
See the example caption above for description.

General Techniques for Checkpoint B.3.3:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique B.3.3-General.1 [Advisory]: Grouping input controls when several pieces of information are all required from the author as part of an accessible authoring practice.

ATAG Checkpoint B.3.4: Ensure that features of the authoring tool that support the production of accessible content are configurable. [Priority 3] (Rationale)

Techniques for Success Criterion 1 (All accessible content support features must be turned on by default):

Applicability: This success criterion is only applicable to authoring tools that provide accessible content support features (e.g., accessibility prompting, checking, repair).

Technique B.3.4-1.1 [Sufficient]: Ensuring that all accessible content support features are turned on by default within the authoring tool preferences area.

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 B.3.4-1.1: The preference setting area of a given authoring tool, open to an "Accessibility" section. The mockup begins with an area for setting the "Target Accessibility Standards". The author has the option selecting "W3C-WCAG" and a level (e.g. "Double-A"), "U.S. Section 508", or a custom setting via the "Customize..." button. (All of the following options are considered "continuously active" for the purpose of the technique). The author has the following "Accessibility Checking" options: "Check accessibility as you type", "Check accessibility after saving", and "Auto-correct when possible". They also have the following "Accessibility Highlighting" options: "Highlight accessibility related fields" and "Prompt when highlighted fields are left blank". And finally the author has an "Accessibility Help" option: "Provide accessibility 'Quick Tips'". (Source: mockup by AUWG)
See the example caption above for description.

Techniques for Success Criterion 2 (If the author does turn off an accessible content support feature, then the authoring tool must inform the author that this may increase the risk of content accessibility problems.):

Applicability: This success criterion is only applicable to authoring tools that provide a way to turn off accessible content support features (e.g., accessibility prompting, checking, repair).

Technique B.3.4-2.1 [Sufficient]: Providing the author with a warning whenever an accessible content support feature is turned off (e.g., from the authoring tool preferences area.

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 B.3.4-2.1: In an authoring tool, the author has unchecked a "highlighting accessibility related fields" feature the tool. As a result the tool displays a warning that reads "You have just turned off the highlighting accessibility related fields feature. This feature is designed to inform you when information must be provided in order for your documents to comply with your target accessibility setting. Turning this feature off could cause your documents to be less accessible to many users. In some jurisdictions accessibility is a legal requirement. Are you sure you want to proceed?". The author has the option to answer "Yes", "No" or "Cancel". (Source: mockup by AUWG)
See the example caption above for description.

Techniques for Success Criterion 3 (If the author does turn off an accessible content support feature, then the author must always have the option to turn the feature back on again.):

Applicability: This success criterion is only applicable to authoring tools that provide a way of turning off accessible content support features (e.g., accessibility prompting, checking, repair).

Technique B.3.4-3.1 [Sufficient]: Providing an authoring tool preferences area where the deactivated features can be reactivated.

Techniques for Success Criterion 4 (The accessible content support feature settings must be saved between authoring sessions.):

Applicability: This success criterion is only applicable to authoring tools that provide preference settings for accessible content support features (e.g., accessibility prompting, checking, repair).

Technique B.3.4-4.1 [Sufficient]: Saving all author settings between sessions

General Techniques for Checkpoint B.3.4:

Applicability: Techniques in this section are not necessarily applicable to any one success criteria, and may apply more generally to the checkpoint as a whole.

Technique B.3.4-General.1 [Advisory]: Enhancing configurability of accessibility features beyond what exists for other related features. Some potential configuration options:

ATAG Checkpoint B.3.5: Document features of the authoring tool that support the production of accessible content. [Priority 1] (Rationale)

Techniques for Success Criterion 1 (All accessible content support features must be documented in the help system):

Applicability: This success criterion is only applicable to authoring tools that provide accessible content support features (e.g., accessibility prompting, checking, repair).

Technique B.3.5-1.1 [Sufficient]: Ensuring that the help system answers the question "What features of the tool encourage the production of accessible content?" with reference to all of the accessible content support features. Also ensuring that, for each feature identified, the help system answers the question "How are these features operated?".

Technique B.3.5-1.2 [Advisory]: Providing direct links from accessible content support features to context sensitive help on how to operate the features.

Technique B.3.5-1.3 [Advisory]: Providing direct links from within the accessibility related documentation that take the author directly to the relevant accessible content support features.

ATAG Checkpoint B.3.6: Ensure that any authoring practices demonstrated in repair instructions and documentation are accessible. [Priority 3] (Rationale)

Techniques for Success Criterion 1 (All examples of markup and screenshots of the authoring tool user interface that appear in the documentation and repair instructions must demonstrate accessible Web content, with the exception of examples specifically intended to show inaccessible practices which must be avoided.):

Applicability: This success criterion is applicable to authoring tools that include documentation on how to author content and/or repair instructions that are meant to be used by authors to fix existing content problems (e.g., accessibility problems, validity problems, etc.).

Technique B.3.6-1.1 [Sufficient]: Ensuring that all examples of content pass the tool's own accessibility checking mechanism (see Checkpoint B.2.1). Also ensuring that all screenshots of the authoring interface show the authoring interface in a state that corresponds to full and proper use of the accessibility features of tool (e.g., prompts filled in, optional accessibility features turned on, etc.).

Applicable to Code-Level authoring functions Example B.3.6-1.1: Documentation for the input element in this code-level authoring tool makes use of the label element in an example in order to reinforce the routine nature of the pairing. The help text reads: "Input Element: Input elements are form controls. They let the reader of your page use text entry, checkboxes, radio buttons, etc. to interact with your page. The most important attribute of the INPUT element is type. The value of type can be: button, checkbox, file, hidden, image, password, radio, reset, submit, and text. Examples:<label>Enter your name: <input type="text" name="name" maxlength="30"></label><input type="submit">. (Source: mockup by AUWG)
See the example caption above for description.

Technique B.2.8-1.2 [Advisory]: Providing, In the documentation, at least one model of each accessibility practice in the relevant WCAG techniques document for each language supported by the tool. Include all levels of accessibility practices.

Technique B.2.8-1.3 [Advisory]: Ensuring that plug-ins that update the accessibility features of a tool also update the documentation examples.


[Contents] [Part A] [Part B] [References]