Implementing ATAG 2.0

Intent of Success Criterion A.1.1.1:

The intent of this success criterion is to ensure that authoring tool user interfaces that are fully or partially web-based are accessible to authors with disabilities. Since WCAG 2.0 already provides requirements for the accessibility of web content, including web applications, those guidelines are referenced to avoid replication of requirements.

Some of the success criteria in Part A are based on WCAG 2.0. This occurs in order to ensure that the requirement will be followed by authoring tools that are not web-based. In most cases, the requirements are identical, so web-based authoring tool user interfaces that meet A.1.1.1 will automatically meet the other requirements. However, there are some cases where the success criteria differ. These cases will be highlighted in the respective "Intent" sections.

Examples of Success Criterion A.1.1.1:

• Web-based authoring tool: A web-based wiki application is designed to conform to WCAG 2.0 Level A. During development, all parts of the user interface (including editing-views rendering test content) are tested by the developer using an accessibility evaluation harness for web applications. Periodically, the application is also tested by authors using assistive technologies.
• Web-based help system: A non-web-based authoring tool makes use of a web-based help system. Each page in the help system is based on a template that was designed to conform to WCAG 2.0 Level A (when used) and the developer ensures that each help page passes an accessibility checker before being published. The developer confirms the accessibility of the final help system by spot-checking sample pages.

Related Resources for Success Criterion A.1.1.1:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion A.1.2.1:

The intent of this success criterion is to ensure that authoring tool user interfaces that are not web applications are accessible to authors with disabilities. In formulating a requirement that would best fulfill this intent, the Working Group decided upon a requirement to follow and cite the accessibility standards and platform conventions that already exist for many platforms. It was decided that this was the best approach because:

1. the "accessibility standards" wording allows developers the scope to harmonize with accessibility legislation in their markets.
2. "platform conventions", by their nature, include platform-specific details such as API calls and look-and-feel examples that generic software guidance cannot.
3. "accessibility standards" and "platform conventions" will continue to progress even after the publication of these guidelines.
4. the note to cite, in any conformance claims, the accessibility standards and/or platform conventions that were followed, should mean that reputable developers will refrain from implementing obscure or weak requirements.

Note: Developers should take note of the documents listed in the "Related Resources for Success Criterion A.1.2.1" section, below. Unless extenuating circumstances exist (e.g., a document has been superseded, the platform has undergone major architectural changes), the listed resources should be assumed to be relevant to the platforms listed.

Examples of Success Criterion A.1.2.1:

• WYSIWYG on Mac OS: A WYSIWYG text editor is designed in Cocoa following the Mac OS X accessibility framework including using Accessibility Objects setting attributes for Role, Role Description, Description, Title, Relationship and Value. No custom actions are defined and all actions can be performed through the keyboard. Hit-testing has been implemented to pass current focus to assistive technologies. The recommended and reserved keyboard shortcuts for Apple Human Interface Guidelines and for Mac OS X accessibility are included in the application and not overwritten. The conformance claim includes links to the Accessibility Programming Guidelines for Cocoa and the Accessibility Keyboard Shortcuts as applicable.
  
• Content management system on Windows: A content management system is written to operate on the Windows XP and Vista operating systems following Microsoft's Active Accessibility. The programs uses IAccessible proxies and only implements IAccessible for controls that are not proxied by OLEACC. The conformance claim includes links to the applicable Microsoft Developer Network documents.

Related Resources for Success Criterion A.1.2.1:

• The following is a non-exhaustive list of accessibility guidelines and best practice documents for various platforms (for information related to keyboard shortcuts, see Success Criterion A.3.1.5):
  • Android: Example from Android Developer Reference
  • BlackBerry: BlackBerry Accessibility
  • Eclipse: Designing Accessible Plug-ins in Eclipse
  • Gnome: GNOME Accessibility Developers Guide
  • KDE: Developer's Information
  • Java SE: Java SE Desktop Accessibility
  • Lotus Notes: Lotus Notes checklist
  • Mac OS: Accessibility Overview
  • Microsoft Windows: Accessibility Overview
  • iPhone OS: Accessibility Programming Guide for iPhone OS
  • General Guides:
    • ISO 9241-171:2008 Ergonomics of human-system interaction - Part 171: Guidance on software accessibility
    • Software Checklist (IBM)

Intent of Success Criterion A.2.1.1:

The intent of this success criterion is to ensure that authors with disabilities have access to alternative content in the web content that they are editing, because this information can help authors orient and navigate as they edit.

The intent of the "recognized" condition is to acknowledge that "alternative content" may appear in web content in ways that software is not able to detect (e.g., when captions are added directly to the main video track). As per the definition of "recognized", the forms of alternative content that the authoring tool recognizes are to be listed in any conformance claim.

Web-based authoring tools will already be required to meet this success criterion as part of Success Criterion A.1.1.1.

Examples of Success Criterion A.2.1.1:

• WYSIWYG editing-view: A WYSIWYG editing-view is implemented using a browser component that meets the requirements in the User Agent Accessibility Guidelines (UAAG) 1.0 that are relevant to the processing of alternative content (e.g., displaying captions, ensuring alternative text can be programmatically determined).
• Source content editing-view: A source content editing-view displays plain text alternative content, providing authors with direct access to any alternative content and the ability to edit it directly.

Related Resources for Success Criterion A.2.1.1:

• User Agent Accessibility Guidelines (UAAG) 1.0.
• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Guideline 1.1 and Guideline 1.2 and the section Understanding "Text Alternatives".

Intent of Success Criterion A.2.2.1:

The intent of this success criterion is to ensure that if the authoring tool makes changes to the display of the web content being edited in order to communicate with authors (e.g., to highlight spelling errors, identify the location of markup tags, etc.), then authors with disabilities will have the same access to that information as other authors.

Examples of Success Criterion A.2.2.1:

• Change tracking feature: A web-based authoring tool includes a change tracking feature that displays inserted text in green and deleted text in red with a strike-through style. Instead of implementing this using simple CSS selectors, the authoring tool uses the XHTML elements ins and del, since these have semantic meaning.

Related Resources for Success Criterion A.2.2.1:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Success Criterion 1.3.1.

Intent of Success Criterion A.2.2.2:

The intent of this success criterion is to ensure that authors with disabilities have access to text presentation information that is made available to other authors by editing-views. This is important because authors who cannot see still need to understand how their web content will appear to end users who can, once it is published.

This success criterion pertains to the rendered properties of text on the screen, even if the properties differ from the web content being edited. For example, when authors have chosen custom display settings (as per Success Criterion A.2.3.1).

Examples of Success Criterion A.2.2.2:

• Non-web-based authoring tool:
  A non-web-based authoring tool includes a WYSIWYG editing-view that implements the appropriate platform accessibility architecture. Included in the information passed to the platform accessibility architecture is information on the size, font, foreground and background color, font weight, and position of any rendered text.
• Web-based authoring tool:
  A web-based WYSIWYG authoring tool uses style sheets to control text presentation, enabling the presentation information to be programmatically determined by the user agent, which passes it on to the appropriate platform accessibility architecture (the user agent is cited in any conformance claim).

Related Resources for Success Criterion A.2.2.2:

• For non-web-based authoring tool, see the "Related Resources" for Success Criterion A.1.2.1.

See Implementing Success Criterion A.2.2.2, substituting all text presentation properties that are both rendered and editable by the authoring tool for the four presentation properties listed in A.2.2.2.

Intent of Success Criterion A.3.1.1:

The intent of this success criterion is to ensure that almost all authoring tool functionality can be operated using a keyboard or an assistive technology that makes use of a keyboard interface, such as onscreen scanning keyboards and voice recognition systems.

The only exemption at Level A to this requirement involves functions that require input that depends on the path of the user's movement and not just the endpoints. This is a very narrow exception related to web content properties containing hundreds or thousands of numerical values. The exception exists because it is not reasonable to expect that authors using only a keyboard would be prepared to hand-code so many data points. The exception does not apply simply because the developers of an authoring tool have decided to use mouse input to control functionality in the past (e.g., setting the endpoints for straight lines, rectangles and circles). The exception also does not apply simply because a functionality is related to graphics. Also, the exception applies to the editing of particular properties. While editing the path of a freehand curve may be exempt, setting the line color and thickness likely is not exempt. Finally, this is a Level A exception only. There is no exception for the Level AAA requirement (Success Criterion A.3.1.4).

The intent of Note 1 is to clarify that the exception applies to the underlying function and that pointing device input variables, such as pressure, speed and angle, are also covered..

The intent of Note 2 is to clarify that rather than replacing other types of interaction, the keyboard access requirement is to provide an alternative.

Examples of Success Criterion A.3.1.1:

• Drag-and-drop feature: An authoring tool allows authors to open documents by dragging them into the authoring tool window. The same operation can be performed from the menus using the keyboard.
• Keyboard manipulation of drawing objects: A multimedia authoring tool allows authors to navigate the selection focus between all of the drawing objects on the canvas. Once an object is selected, it can be manipulated with keyboard-driven menu commands, some of which have keyboard shortcuts (e.g., arrow keys to move the object, etc.). New drawing objects can also be added from the keyboard-driven menus.
• Keyboard manipulation of drawing object properties: A multimedia authoring tool does not include keyboard access to the drawing canvas directly, but instead provides a keyboard accessible list of drawing objects that allows a keyboard editable property page to be brought up. The property page includes properties such as "top", "left", "width", "height", "rotation", and "label". When these properties are adjusted, the objects on the canvas are updated accordingly. New drawing objects can be added from the keyboard-driven menus.
• Select and operate: An authoring tool provides editing functionality in which authors can select content in the editing-view (e.g., select text) and then perform an operation (i.e., authoring action) on that selection (e.g., formatting, deletion, etc.). Keyboard access to this functionality is enabled by the fact that the selection can be made using the keyboard and that the selection is maintained while the author uses the keyboard to navigate the authoring tool user interface to arrive at the operation they want to perform.
  

Related Resources for Success Criterion A.3.1.1:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Success Criterion 2.1.1.

Intent of Success Criterion A.3.1.2:

The intent of this success criterion is to ensure that neither the authoring tool's own user interface nor any rendered web content within editing-views "traps" keyboard focus. This is problem may occur when an interactive object is embedded in content. Authors might be able to move focus to the object (e.g., by using the "tab" key) within a WYSIWYG editing-view, but they are unable to move the focus out using the keyboard, because keyboard control has passed to the embedded object.

The first requirement (a) applies only to the authoring tool user interface, which is the part of the authoring tool that developers have the most control over. In this case, there should not be any keyboard traps. If authors can move focus to a component using standard keyboard navigation commands (e.g., using the tab key), then they must be able to move focus out of the component in the same way or be advised of the method.

The second requirement (b) applies to renderings of web content. Because the content may contain keyboard handlers, the authoring tool may not be able to prevent keyboard traps entirely. Therefore, the requirement is only that the authoring tool be able to restore the keyboard focus to some known location.

Examples of Success Criterion A.3.1.2:

• Non-web-based authoring tool: A non-web-based authoring tool has a user interface that has been thoroughly tested by the developer to ensure that no keyboard traps exist. If authors open web content containing keyboard traps in the WYSIWYG editing-view, the authoring tool allows authors to restore keyboard focus to the top of the editing-view at any time by pressing the "Home" key, which the authoring tool never passes to the content being edited.
• Web-based authoring tool: A web-based authoring tool has a user interface that has been thoroughly tested by the developer to ensure that no keyboard traps exist. If authors open web content containing keyboard traps, the authoring tool relies on a feature in the authors' user agent that always restores keyboard focus to the address bar (the user agent is cited in any conformance claim).

Related Resources for Success Criterion A.3.1.2:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Success Criterion 2.1.2.

Intent of Success Criterion A.3.1.3:

The intent of this success criterion is to ensure that authors using a keyboard interface effectively access the functionality of the authoring tool, especially the commonly used features. The wording is intentionally general because the number and nature of keyboard shortcuts that are available in various operating environments varies greatly as do the features that are most commonly used. For example, desktop environments, with a full keyboard, generally have a reasonably large set of keys available for developers to directly link to particular functionality (e.g., the "ctrl" + "S" key combination can be directly mapped to the "Save" function). In contrast, web-based applications are not able to rely on keys that are already used by the various browsers. This leaves very few keystrokes available, even from a full keyboard. In mobile environments, with very few physical keys, the possibilities are even more limited.

Therefore, developers should interpret "keyboard shortcut" in this success criterion to include any keystroke controlled mechanism that "shortcuts" the need for authors using keyboard interfaces to navigate sequentially through all of the control functionality. In other words, any mechanism that increases the efficiency of operating the authoring tool with a keyboard only. That said, direct keystroke mapping (e.g. "ctrl"+"S") are the most efficient mechanisms for keyboard control and these should be provided where possible.

Examples of Success Criterion A.3.1.3:

• In a desktop environment: A non-web-based authoring tool provides keyboard shortcuts for its menu functions as well as access keys in the design of its menus and dialog boxes. The choice of shortcut keys follows platform conventions where applicable, for example for open document, save document, cut, copy, paste, etc..
• In a mobile environment: A social networking application on a mobile device has only a very few keyboard shortcuts available on its targeted devices. These few keyboard shortcuts are used for the most commonly accessed functions of the application (e.g., home, list of friends).
• In a web-based environment: A web-based CMS uses links to allow authors to skip between the toolbars and directly to the content editing area.

Related Resources for Success Criterion A.3.1.3:

• The following is a non-exhaustive list of keyboard shortcut conventions for various platforms:
  • BlackBerry: UI Guidelines - BlackBerry Smartphones - Best practice: Implementing shortcut keys
  • Gnome: GNOME Human Interface Guidelines 2.2 - Keyboard Interaction
  • Microsoft Windows: Keyboard Shortcuts for Windows
  • Eclipse: Eclipse Keyboard Shortcuts
  • Java SE: Java Look and Feel Design Guidelines: Keyboard Operations
  • Lotus Notes: Keyboard shortcuts in Notes 6.x and Notes 7.x
  • Mac OS: Mac OS X keyboard shortcuts

Intent of Success Criterion A.3.1.4:

The intent of this success criterion is to establish an enhanced requirement for keyboard access, without any exceptions. While some "high-end" drawing features, such as a "watercolor painting" tool that continuously sampled the path, pressure and angle of a stylus would be very challenging to make fully keyboard accessible, other less complex functions might be practical.

Web-based authoring tools will already be required to meet this success criterion as part of Success Criterion A.1.1.1.

Examples of Success Criterion A.3.1.4:

• Keyboard-driven "freehand" drawing: A multimedia authoring tool has a mode that allows "freehand" lines to be drawn in increments, letting authors use the keyboard to choose the angle and length of the next increment, after which the shape is smoothed.

Related Resources for Success Criterion A.3.1.4:

• N/A

Intent of Success Criterion A.3.1.5:

The intent of this success criterion is to ensure that authors using a keyboard interface have the ability to remap the authoring tool's keyboard shortcuts in order to avoid keystroke conflicts, use familiar keystroke combinations and optimize keyboard layout (e.g., for one handed use).

Examples of Success Criterion A.3.1.5:

• Non-web-based authoring tool: A non-web-based authoring tool has a keyboard setup utility that lists all of the available keyboard shortcuts and allows authors to associate each shortcut with any of the authoring tool's commands (e.g., all of the menu commands).
• Web-based content management system: A web-based content management system has a keyboard setup utility that allows authors to change the access keys that are available during authoring. These access key rebindings are for the authors' use only and do not affect the web content being edited.
• Social networking application on a mobile device: A social networking application has a keyboard setup utility that allows authors to change their keyboard shortcuts for the site. The remapping is saved in site cookies.

Related Resources for Success Criterion A.3.1.5:

• N/A

Intent of Success Criterion A.3.1.6:

The intent of this success criterion is to ensure that authors using a keyboard interface have the ability to both discover and be reminded of keyboard shortcuts, – while they are using the authoring tool.

Examples of Success Criterion A.3.1.6:

• Non-web-based authoring tool: When authors press a modifier key in a non-web-based authoring tool (e.g., the "Ctrl" key), all of the keyboard shortcuts in the authoring tool user interface are displayed along with any existing text labels or icons.

Related Resources for Success Criterion A.3.1.6:

• N/A

Intent of Success Criterion A.3.2.1:

The intent of this success criterion is to ensure that the work of authors is saved in the event that an authoring session is ended due to a time limit (e.g., the timeout of an authenticated authoring session). Reducing the likelihood of lost content edits will benefit all authors, but especially authors with disabilities who may take longer to accomplish authoring tasks.

For web-based authoring tools, this applies to any web content that has already been submitted to the server by the user agent.

Examples of Success Criterion A.3.2.1:

• Save and continue: A web-based content management system has a "Save and Continue" button that allows authors to continually submit their content edits without requiring them to re-enter the editing-view afterwards.
• Wiki: A wiki has an auto-save feature that can be turned on by authors. The auto-save feature always saves before a system timeout.

Related Resources for Success Criterion A.3.2.1:

• N/A

Intent of Success Criterion A.3.2.2:

The intent of this success criterion is to ensure that authoring tools provide authors with disabilities adequate time to perform their tasks. Any process that happens without author initiation after a set time or on a periodic basis is a time limit. This includes partial or full updates of the screen (for example, page refresh), or the expiration of a window of opportunity for authors to react to a request for input. It also includes user interface functionality that is advancing or updating at a rate beyond the ability of authors to read and/or understand it. In other words, animated, moving or scrolling information introduces a time limit.

Generally, turning off time limits is better than customizing the length of time limits, which is better than requesting more time before a time limit occurs. In some cases, however, it is not possible to change the time limit (e.g., a collaborative authoring session) and exceptions are therefore provided for those cases.

Web-based authoring tools will already be required to meet this success criterion as part of a Success Criterion A.1.1.1.

Examples of Success Criterion A.3.2.2:

• Web-based content management system: A web-based content management system has a login timeout function that automatically logs authors out after 20 minutes of inactivity. One minute before the automatic log out, the system notifies authors that they will be logged out unless they cancel the notification (meeting (c)). The system also includes a preference setting that lets authors set the timing of the notification up to 10 minutes before the automatic logout (meeting (b)).
• Real-time collaborative editing system: A real-time collaborative editing system allows multiple authors to edit the same web content simultaneously. An integral part of the real-time collaborative activity is that any author may edit or delete what others have just authored (meeting (d)).

Related Resources for Success Criterion A.3.2.2:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Success Criterion 2.2.1.

Intent of Success Criterion A.3.2.3:

The intent of this success criterion is to ensure that authors are not prevented from using the authoring tool by a requirement for fast reactions.

Examples of Success Criterion A.3.2.3:

• Timeline-based authoring tool: A timeline-based interactive web content editor has an indicator of the current position on the timeline that authors can click and drag. When the interactive content is being previewed, the indicator moves along the timeline, which can make it difficult to target with the mouse. Authors can stop the indicator from moving by selecting the "Stop" or "Pause" buttons.

Related Resources for Success Criterion A.3.2.3:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Success Criterion 2.2.2.

Intent of Success Criterion A.3.2.4:

The intent of this success criterion is to ensure that the work of authors is saved in the event that an authoring session is ended due to a time limit. Reducing the likelihood of lost content edits will benefit all authors, but especially authors with disabilities who may take longer to accomplish authoring tasks. Increasing the frequency with which content edits are saved also helps authors recover more easily from inadvertent actions.

Examples of Success Criterion A.3.2.4:

• Web-based content management system: The system includes an option to turn on asynchronous server communication to constantly save authoring actions into a backup file. If the authoring session ends unexpectedly, authors can retrieve backups during their next authoring session.

Related Resources for Success Criterion A.3.2.4:

• N/A

Intent of Success Criterion A.3.3.1:

The intent of this success criterion is to ensure that authors with photosensitive seizure disorder can use the authoring tool to open time-based web content without risk. Some people with seizure disorders can have a seizure triggered by flashing visual content.

Examples of Success Criterion A.3.3.1:

• Blog: A blogging tool allows authors to import video files. Authors have the option to turn off an auto-play feature, so that the video files are not played until a "Play" button is activated.
• WYSIWYG web page editor: A WYSIWYG editing-view is capable of rendering JavaScript in real-time. Authors have the option to turn off the real-time rendering feature, so that the JavaScript is not rendered until a "Play" button is activated.

Related Resources for Success Criterion A.3.3.1:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Guideline 2.3.

Intent of Success Criterion A.3.4.1:

The intent of this success criterion is to let authors make use of the structure that may be present in the web content that they are editing to more efficiently edit that content. This is particularly important when authors are editing large amounts of content. Of course, the editing mechanisms are contingent on the content containing the appropriate structure. For example, editing by structure would not be very effective in an HTML document composed of plain text in a pre element.

Examples of Success Criterion A.3.4.1:

• WYSIWYG web page editor: A WYSIWYG editing-view allows authors to select and manipulate elements as objects. When an element is selected, any content (including sub-elements) of the element are also selected. When authors perform a function on a selected element, the scope of the function and the resulting outcome depends on the nature of the function.
  • Some functions target the entire selection (i.e., the element, content and sub-elements). For example, when a <table> element is selected and the "delete" operation is performed, the entire table is deleted, including sub-elements (tr and td) and any text content etc. within the table.
  • Some functions only target the top level element of the selection. For example, the "strip element tag" function deletes the markup of the top level element without affecting its sub-elements or content.
  • Some functions only target the content, including sub-elements of the top level element of the selection without having any affect on the markup of that top level element. For example, the “replace contents” function is a variant of "paste" in which the sub-elements and content of the selected element are replaced.

Related Resources for Success Criterion A.3.4.1:

• N/A

Intent of Success Criterion A.3.4.2:

The intent of this success criterion is to help authors using a keyboard interface to navigate more efficiently within structured web content. Because web content technologies differ in the types of structure that they include, developers have flexibility to decide what types of navigation mechanisms to include. The following list contains some possibilities:

1. tree navigation: the ability to move focus to the elements up, down and across tree structures.
2. navigation by headers: the ability to move focus between elements identified as headers in the markup (e.g., h1, h2, etc in HTML4).
3. navigation by element: the ability to move focus between element of the same type or sharing particular attributes.
4. navigation by role: the ability to move focus between elements identified by their roles.
5. navigation by accessibility relationships: the ability to move focus between elements bound by accessibility relationships (for attribute of label in HTML4, aria-describedby, etc.).

Of course, the navigation mechanisms are contingent on the content containing the appropriate structure. For example, navigation by headers would not be very effective in an HTML document that did not contain headers.

Examples of Success Criterion A.3.4.2:

• Source content editing-view: A source content editing-view supports authors by providing the ability to use keyboard shortcuts to move the focus from any element (e.g., table row) to:
  • the element immediately above (e.g., table),
  • the first element immediately below (e.g., table data cell),
  • the element immediately preceding it at the same level (e.g., previous table row), and
  • the element immediately following it at the same level (e.g., next table row).
• Search by any header element: An authoring tool includes a search function mode that enables authors to search forwards or backwards by "any header element". For example, in HTML4 this would be h1, h2, h3, h4, h5, and h6. When a searched-for header element exists, it is selected in the editing-view, enabling authors to immediately edit the element.
• Search by element: An authoring tool includes a search function mode that enables authors to search forwards or backwards by the names of elements. When a searched-for element exists, it is selected in the editing-view, enabling authors to immediately edit the element. In addition, the search can be customized to search by attributes, etc.
  Figure: A "Find and Replace" dialog box is shown configured to find the "element" with the name "img", "with attribute" "height" "=" "100" ( where each value in quotation marks is editable). The replacement action is to "set attribute" "height" to "50". The following checkbox options are available "match case", "ignore white space" and "search text alternatives". The dialog box also includes the following buttons "Find Next", "Find all", "Replace", "Replace All", "Close" and "Help". (Source: mockup by AUWG)
  
• Outline view: An "outline" or "structure" editing-view is provided that organizes structured element sets being edited into a document tree. In this editing-view, only the arrow keys are required for navigation between the parent, child and sibling elements.
• Customizing widgets: An authoring tool enables authors to add and customize JavaScript widgets in its WYSIWYG editing-view. Authors can use the keyboard to navigate through the elements that make up the widget in order to set the properties or appearance of the widget. For example, in a slider widget, the keyboard can be used to select the background, the line, the line ticks or the thumb marker of the slider.

Related Resources for Success Criterion A.3.4.2:

• N/A

Intent of Success Criterion A.3.5.1:

The intent of this success criterion is to ensure that authors can efficiently find the web content that they wish to edit.

The intent of the note under (a) is to acknowledge that not every editing-view is capable of editing every type of content that can be searched (e.g., a WYSIWYG editing-view may not be able to display search results within markup tags).

Examples of Success Criterion A.3.5.1:

• Basic text search: An authoring tool provides both WYSIWYG and source content editing-views. The authoring tool provides two-way, case sensitive searching for plain text sequences within both editing-views. The default search option is to search only within the editing-view that the author is currently working within. However, there is an option to search both editing-views simultaneously. When this option is selected, the search results are all displayed in a selectable list that labels each as "Text" or "Source Code", reflecting which editing-view will become active when the author selects the search result.
• Advanced text search: An authoring tool's basic text search feature is augmented by more advanced search options, such as:
  • replacement,
  • wildcard characters,
  • whole word matching,
  • search repetition, and
  • highlighting of all occurrences.
• Metadata editor: A metadata editor provides two-way, case sensitive searching for plain text sequences within textual metadata fields (e.g., title, description, author, etc.).

Related Resources for Success Criterion A.3.5.1:

• N/A

Intent of Success Criterion A.3.6.1:

The intent of this success criterion is to ensure that the preference display settings that authors set for their own use while they are editing web content are independent of the display settings that are encoded (and eventually published) in the content being edited.

When "WYSIWYG authoring tools" are referred to in the examples, it is with the understanding that browsers will differ in their renderings of the same content and that end users are often free to override the default presentation of web content.

Examples of Success Criterion A.3.6.1:

• Editing-view preferences: A non-web-based WYSIWYG authoring tool has preference settings that enable authors to override the default rendering styles used in the WYSIWYG editing-view with the display settings that they have already set in the operating system (e.g., large fonts, high contrast mode, etc.). The preference settings have absolutely no effect on the web content being edited.
• Setting an authoring style sheet: A WYSIWYG authoring tool has preference settings that enable authors to set an "authoring" style sheet. This style sheet is only used to control the rendering of the web content in the author's editing-view. The stylesheet does not make changes to the content markup being edited and is not published to end users.
• Web-based authoring tool: A web-based authoring tool lets authors customize the appearance of editing-views using the preference display settings of the user agent (the user agent is cited in any conformance claim).

Related Resources for Success Criterion A.3.6.1:

• N/A

Intent of Success Criterion A.3.6.2:

The intent of this success criterion is to ensure that authors' preference settings for keyboard and display settings do not need to be reset for each authoring session.

Examples of Success Criterion A.3.6.2:

• Storing preferences with author account: A web-based authoring tool requires that authors log in to their accounts before authoring sessions can begin. Because preference settings are associated with author accounts, the settings are applied as soon as authors log in.

Related Resources for Success Criterion A.3.6.2:

• N/A

Intent of Success Criterion A.3.6.3:

The intent of this success criterion is to encourage authoring tools to respect the display and control settings that authors have already specified at the platform level. This reduces the need for authors to repeatedly specify the same preferences. It also means that when authors first open the authoring tool, they can more easily use the tool.

The intent of the note is to remind implementers of Success Criterion A.3.6.1, which requires that there be independence between the settings that authors choose for their own work environment and the characteristics they set for the web content that they are editing.

Examples of Success Criterion A.3.6.3:

• Desktop high contrast mode: A non-web-based authoring tool defaults to high contrast mode when it detects that the platform is set to high contrast mode.
• Web-based authoring tool: A web-based authoring tool respects the display and control settings of the user agent on which it is running.

Related Resources for Success Criterion A.3.6.3:

• N/A

Intent of Success Criterion A.3.6.4:

The intent of this success criterion is to ensure that authors whose personal preferences vary over time (e.g., due to fatigue) can easily select from a series of pre-set preferences for display and control settings.

Examples of Success Criterion A.3.6.4:

• Basic multiple profiles: An authoring tool allows the various configurations of preference settings to be stored as different profiles that authors can switch between at any time. The stored preference settings include all display and control settings that are specific to the authoring tool (i.e., are not controlled by the platform).
• Portable profiles: An authoring tool's basic multiple profiles feature is augmented by the ability for authors to save the profiles as separate files. This allows authors to move configurations between instances of the authoring tool on different systems or to share the configuration files with other authors with similar requirements.

Related Resources for Success Criterion A.3.6.4:

• N/A

Intent of Success Criterion A.3.6.5:

The intent of this success criterion is to ensure that authoring tools provide assistance to authors in configuring any options related to the accessibility of the user interface. This assistance should include extra assistance resolving any incompatibilities between options (e.g., prevent the same color being used for both the foreground and background).

Examples of Success Criterion A.3.6.5:

• Options setting wizard: An authoring tool includes a wizard that takes authors step-by-step through the accessibility options, providing explanations and previews of how the options will change the display. The wizard follows an interview format, first asking authors about general areas (e.g., seeing the screen, using the keyboard) and then becoming more detailed (e.g., text size, text color, etc.).

Related Resources for Success Criterion A.3.6.5:

• N/A

Intent of Success Criterion A.3.7.1:

The intent of this success criterion is to ensure that preview features strike a balance between giving authors with disabilities an accessible means of previewing the web content that they are editing and not giving those authors an unrealistic impression of how end users with similar disabilities will actually experience that content in their own user agents (e.g., browser, video player, etc.). In other words, it is not necessarily useful to present a user experience with content as a "preview" when it is much more accessible than the actual end user experience of the content would be in a pre-existing user agent.

The most straightforward way to meet this success criterion is for authoring tools to implement preview features using user agents that are already in use by end users - see (a). This might be done in several ways, including by opening the content in the author's default user agent or by making use of a user agent widget nested within the authoring tool's own user interface (the user agent is cited in any conformance claim).

On the other hand, if a preview is being developed that is already a departure from existing user agents, then the W3C User Agent Accessibility Guidelines (UAAG) must be followed - see (b). At the time of publication, UAAG version 1.0 is a W3C Recommendation and version 2.0 is under development.

Note: Developers may develop a preview from scratch that does not meet (b) as long as authors retain the option to preview using their own user agent, since this meets (a).

Examples of Success Criterion A.3.7.1:

• Preview in a user agent: A web-based authoring tool performs previews by opening the web content in a new user agent tab or window.
• Preview in an external user agent: A non-web-based authoring tool performs previews by opening the web content to be previewed in the user's default browser.
• Preview in a user agent component: A non-web-based authoring tool performs previews using a user agent component that is built directly into the authoring tool.
• Custom built preview: An authoring tool makes use of a custom built preview feature. The preview feature conforms to User Agent Accessibility Guidelines (UAAG) 1.0 at Level "A".

Related Resources for Success Criterion A.3.7.1:

• User Agent Accessibility Guidelines (UAAG) 1.0.

Intent of Success Criterion A.3.7.2:

The intent of this success criterion is to provide a AAA-level requirement in which authors have the flexibility to choose their preferred user agent for performing previews.

Examples of Success Criterion A.3.7.2:

• Preview options: Authors have the option of choosing from any of the user agents installed on their computer to perform the preview.

Related Resources for Success Criterion A.3.7.2:

• N/A

Intent of Success Criterion A.4.1.1:

The intent of this success criterion is to help authors with disabilities avoid serious consequences in the web content that they are editing as the result of a mistake while performing authoring actions. Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error.

The intent of the note is to acknowledge that some implementations of undo may group text entry actions.

The intent of Note 2 is to acknowledge that undo is not always technically possible.

Examples of Success Criterion A.4.1.1:

• Non-web-based authoring tool: An authoring tool has an "Undo" action under the "Edit" menu. Activating the undo action reverses the previous authoring action. Activating "undo" again undoes the previous authoring action and so on.
• Web-based content management system: A web-based content management system supports two types of reversible actions. In the first type, text entry actions into text fields can be reversed using the "undo" feature of the user agent (user agent is cited in the conformance claim). In the second type, "Cancel" buttons are available that allow authors to reverse changes that have already been committed. However, to avoid the "Cancel" button being pressed accidentally, authors have the option of having confirmation dialogs displayed when "Cancel" is activated (see Success Criterion A.4.1.3).

Related Resources for Success Criterion A.4.1.1:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Guideline 3.3.

Intent of Success Criterion A.4.1.2:

The intent of this success criterion is to help authors with disabilities avoid making the authoring tool unusable to them as the result of making a mistake while installing the program or modifying preference settings. Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error.

Examples of Success Criterion A.4.1.2:

• Cancel: On each preference settings page are two options, OK and Cancel. Cancelling prevents the setting changes from being applied.
• All reversible: All of the preference setting changes in an authoring tool can be reversed by revisiting the preference setting utility and adjusting the settings.
• Restore defaults: In a preference setting utility, a "restore default settings" button is always available.

Related Resources for Success Criterion A.4.1.2:

• For web-based authoring tools, see WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially Guideline 3.3.

Intent of Success Criterion A.4.1.3:

The intent of this success criterion is to ensure that an inadvertent "undo" can be reversed, which is sometimes called "re-do". Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error.

Examples of Success Criterion A.4.1.3:

• Web-based content management system: In the "Web-based content management system" example in Success Criterion A.4.1.1, the content management system supports two ways of reversing undo actions. In the first, the redo feature of the user agent (user agent is cited in the conformance claim) can be used to redo text entry that has been reversed with the user agent's undo feature. In the second, confirmation dialogs let the user reverse "Cancel" actions that would discard content changes.

Related Resources for Success Criterion A.4.1.3:

• N/A

Intent of Success Criterion A.4.1.4:

The intent of this success criterion is to ensure that an inadvertent "undo" can be reversed, which is sometimes called "re-do". Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error.

Examples of Success Criterion A.4.1.4:

• ?:?

Related Resources for Success Criterion A.4.1.4:

• N/A

Intent of Success Criterion A.4.2.1:

The intent of this success criterion is to ensure that authors with disabilities that need to use the accessibility features of the authoring tool user interface can easily find specific instruction in the documentation. The intent of the note is to remind implemetors that the accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

Examples of Success Criterion A.4.2.1:

• Accessibility features documented: An authoring tool includes a help system that is always available to authors, is searchable by keyword and is also linked in context from the various features within the authoring tool. The documentation conforms to WCAG 2.0 Level A and includes the following topics grouped together into an "Accessibility Features" chapter in the help system:
  • how to customize display settings
  • what keyboard shortcuts are available, including navigation keys
  • how to customize keyboard shortcuts
  • how to avoid keyboard traps
  • how to extend time limits
  • how to use the search features
  • how to undo/redo
  • how to set accessibility-related options, such as turning off auto-play

Related Resources for Success Criterion A.4.2.1:

• N/A

Intent of Success Criterion A.4.2.2:

The intent of this success criterion is to ensure that authors who need additional support to learn to operate an authoring tool can easily access instructions. The intent of the note is to remind implemetors that the accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

Examples of Success Criterion A.4.2.2:

• All features documented: An authoring tool includes documentation for all of its features.

Related Resources for Success Criterion A.4.2.2:

• "Software Documentation" on Wikipedia

Intent of Success Criterion B.1.3.1:

The intent of this success criterion is to ensure that when authoring tools have been designed to take over responsibility from authors in determining aspects of web content that are important for accessibility, that the content that is actually produced meets WCAG 2.0 Level A by default. If this was not the case, authoring tools could continually introduce web content accessibility problems that authors would then need to check for and repair.

The "when published" clause addresses the fact that prior to publishing, automatically generated content may not be in a form that can be checked for accessibility.

The intent of the note is to make it clear that this success criterion applies to "good faith" efforts by authoring tool developers. These guidelines do not contain any requirement that authors be forced to provide accessibility information, although some constrained use cases (e.g., government or corporate settings) may take that approach.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.3.1:

• Markup behind WYSIWYG: A WYSIWYG web page authoring tool provides authors with a toolbar of options for formatting text. Following the WYSIWYG (what-you-see-is-what-you-get) paradigm, the options are labeled with the visual result (e.g., a bold "B" to represent bold, an italicized "I" to represent italics, etc.) of performing the action however, the content that is automatically generated from those actions actually conforms to WCAG 2.0 (e.g., using strong for bold and em for emphasis).
• Automatic generation with author input: An online photo album allows authors to upload images and then automatically generates content to display the images. Since the album application is not able to automatically generate alternative content for the images that meets WCAG 2.0, authors are prompted for this information.
• Documentation: An authoring tool that employs automatic content generation documents the accessibility of this functionality with reference to particular WCAG 2.0 techniques.

Related Resources for Success Criterion B.1.3.1:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.2.5.1:

The intent of this success criterion is to ensure that when authoring tools select templates or pre-authored content for authors or automatically generate web content from a template, then the web content conforms to WCAG 2.0 Level A by default. If this was not the case, authoring tools could continually introduce accessibility problems that authors would likely not be able to repair.

The intent of the note is to make it clear that this success criterion takes into account that templates are, by their nature, incomplete. In addition, templates are often stored in forms quite different than the final web content that they are used to produce.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.2.5.1:

• Content management system: A content management system offers a variety of templates to authors for different purposes (e.g., information page, interactive form page, registration page, etc.). All of the templates have passed WCAG 2.0 Level A accessibility evaluations when filled in with sample content by authors who follow all of the instructions provided.

Related Resources for Success Criterion B.2.5.1:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.1.2.1:

The intent of this success criterion is to ensure that authors are warned whenever the authoring tool is unable to preserve accessibility information. This may occur when the output format does not support the same accessibility features as the input format (i.e., the examle of a vector graphic being saved as a raster image format) or when an authoring tool has not implemented the necessary data mapping. There is no value judgement is either case. This is simply a requirement that the author be informed when accessibility information that may have taken substantial time to create is lost.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.2.1:

• Similar data structures (meets (a)): A "Save As" feature preserves accessibility information in similar data structures. For example:
  • when converting between HTML and SVG, the contents of alt attributes are stored in desc attributes
  • when saving a word-processor format to markup, headings and list items are transformed into appropriate structural markup
• Dissimilar but accessible (meets (a)): A "Save As" feature preserves accessibility information in a dissimilar, but accessible way, when similar data structures are not available. For example:
  • when transforming a SMIL presentation with a closed-caption text track into a video-only format, authors have the option of converting the closed captions into open-captions encoded in the video file
  • when transforming a table to a list, table headings are transformed into headings and summary or caption information is retained as rendered text content
  • when saving a word-processing format to markup, specialized document features (i.e., footnotes, endnotes, call-outs, annotations, references, etc.) are retained as rendered text content with two-way linking.
• Warning when text is converted to graphics (meets (b)): A "Save As" feature includes the ability to convert textual formats into graphics. However, if this option is selected by authors, they are warned that the output will have web content accessibility problems. They are also advised that style sheets are preferable for presentation control. If authors continue, there is a suggestion to retain the original text as alternative content for the graphical output.
• Copy and paste as transformation (meets (b)): The "Copy" feature of one authoring tool meets places HTML on the system clip-board that includes accessibility information. The "Paste" feature of a different authoring tool only retrieves a subset of the HTML that does not include the accessibility information, but warns the author that pasting from this format may result in lost data.
• Option to cancel (meets (b)): A markup editor has a feature that that automatically removes any attributes or elements that do not appear in the defined DTD when content is opened for editing. Upon activation, the feature notifies authors that content will be deleted with unknown effects for end users. The authors have the option to cancel the operation, in which case the content will not be opened for editing.

Related Resources for Success Criterion B.1.2.1:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.1.2.2:

The intent of this success criterion is to extend the Level A requirement (Success Criterion B.1.2.1), so that the only exception is technical limitations in the output technology.When there is a technical limitation in the output technology, the requirement from B.1.2.1 to warn the user is still in effect.

Examples of Success Criterion B.1.2.2:

• See examples for Success Criterion B.1.2.1.

Related Resources for Success Criterion B.1.2.2:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.1.1.1:

The intent of this success criterion is to ensure that authors who have the motivation and knowledge to create accessible web content using an authoring tool are not prevented from doing so. The subsequent success criteria in Part B will build on this minimal requirement.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.1.1.1:

• Accessible workflow exists: An authoring tool is designed such that accessible web content (conforming to WCAG 2.0 Level A) will result if authors do all of the following:
  • turn on all features that support the production of accessible content; and
  • correctly follow all prompts by features that support the production of accessible content; and
  • uses the accessibility checker, including a final check prior to publishing; and
  • correctly perform any manual checks suggested by the accessibility checker; and
  • correctly repair all of the automatically, semi-automatically or manually identified web content accessibility problems using the automated, semi-automated and manual repair assistance that the authoring tool provides.
• Source content editing-view: An authoring tool is designed around a source content editing-view, allowing motivated and knowledgeable authors to control every detail of the content produced, including following accessible authoring practices.

Related Resources for Success Criterion B.1.1.1:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.3.1.1:

The intent of this success criterion is to help ensure that accessible authoring practices are part of the default workflow of authoring tools.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.3.1.1:

• Only accessible options: A WYSIWYG editing-view does not include any options for authors that will necessarily result in web content that will not conform to WCAG 2.0 Level A.
• De-emphasizing problematic options: A WYSIWYG editing-view emphasizes more accessible choices with a higher position in the menus and a position in user interface shortcuts such as toolbars. Choices that always lead to less accessible web content are de-emphasized with lower menu position.
  Figure: 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.). (Source: mockup by AUWG)
  

Related Resources for Success Criterion B.3.1.1:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.2.1.2:

The intent of this success criterion is to ensure that if authoring tools only allow authors the ability to modify a subset of the properties of a content element, then the properties required for conformance to WCAG 2.0 are included in that subset.

Examples of Success Criterion B.2.1.2:

• Context sensitive properties: A markup authoring tool includes a context sensitive properties pane that displays property fields for the most common subset of attributes associated with the markup element that currently has focus in the editing-view. The attributes that are required for WCAG 2.0 are included in the subset.
  Figure: 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)
  

Related Resources for Success Criterion B.2.1.2:

• Appendix A: Gathering Accessibility Information from Authors
• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.2.1.1:

The intent of this success criterion is to inform authors as early as possible about the degree to which the authoring tool will be able to provide accessible web content production support for the web content technologies that it is capable of producing. If accessibility is part of early decision-making, it will reduce the likelihood that retrofits for accessibility will be required later on.

The success criterion makes no judgment or assumption about the accessibility of web content technologies. Instead, it is assumed that any technology can be made accessible if used properly. For example, a technology with no intrinsic accessibility features can be made accessible in conjunction with another technology (e.g., bitmap images may be made more accessible via HTML text labels).

Instead, the success criterion depends on whether the authoring tool in question actually supports the production of accessible content in the technology through features such as checking and repair or does not. The choice of which technologies to provide accessible content production support for is left completely to the developer (e.g., a developer might decide to begin by adding support to a less-popular technology because a major customer has requested it).

The wording "provides the option of producing" is intended to rule out situations in which authors make technology choices without guidance by the authoring tool (e.g., by hand coding, by specifying a DTD).

The wording "for publishing" is intended to rule out situations in which incomplete content is created in interim formats that are not intended for publishing.

The intent of (a) is that there be a warning before authors have progressed too far with a technology option lacking support for the production of accessible content in the authoring tool. The warning may appear before authors make a selection or after.

The intent of (b) is simply to inform the user, who has now just received a warning that the authoring tool lacks accessibility support for a given technology, that one or more other web content technologies produced by the authoring tool are supported by such accessibility support features. The list may be a partial or complete list of the technologies for which support for the production of accessible content is provided. In either case, it is left to authors, to decide whether any of the listed technologies might be appropriate for the task or whether they will continue on with their original selection.

Examples of Success Criterion B.2.1.1:

• Choosing video formats: A video authoring tool allows authors to save into several video file formats. However, the authoring tool includes a built-in closed-caption editor that only works with one of the file formats. While there is nothing intrinsically "inaccessible" about any of these three video formats, when the option to save is presented, the formats that are not supported by the authoring tool's own closed-caption editor include warnings that caption support is not provided. In the warning's explanation, the video format that is supported by the closed-caption editor is identified.

Related Resources for Success Criterion B.2.1.1:

• N/A

Intent of Success Criterion B.2.1.3:

The intent of this success criterion is to ensure that when web content technologies can only be imported or integrated (but not edited), authoring tools still provide a mechanism for associating the necessary accessibility information. Many authoring tools make a distinction between technologies that the authoring tool actually uses to edit content and other technologies that can only be imported or integrated. For example, most HTML editors can insert images into web pages without the ability to edit the images.

The association of accessibility information can take many forms, depending on the nature of the inserted web content technology and the web content technology that can be edited. In the HTML example, it is straightforward to associate accessibility information for images via the HTML markup (i.e., alt, longdesc). However, if the inserted web content technology can introduce extensive, inaccessible content, then support for linking to conforming alternate versions might be appropriate.

Examples of Success Criterion B.2.1.3:

• Time-based media alternatives: A SMIL authoring tool lets authors create multimedia presentations by pulling together video, audio and timed text objects on to a timeline, even though the tool has no built-in ability to edit these objects. When authors specify information about video to be inserted, they are also provided with the opportunity to associate a timed text object (for captions), an audio object (for audio description), and a secondary video (for sign language interpretation). When authors specify information about audio to be inserted, they are also provided with the opportunity to associate a timed text object (for captions) and a video (for sign language interpretation).
• Data table for a bar graph: A learning content management system has a feature that lets authors insert figures. The feature accepts images, even though the authoring tool has no built-in ability to edit images, but as part of the "figure properties" the authors can identify the figure as a graph. If they choose this option, then the system assists them in creating an accompanying data table using the values used to create the graph.

Related Resources for Success Criterion B.2.1.3:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially the definition of conforming alternate version.

Intent of Success Criterion B.2.4.1:

The intent of this success criterion is to ensure that authors can add alternative content for non-text content and modify that alternative content in the future.

If the type of alternative content (e.g., alternative text) is not typically displayed on screen by user agents, then WYSIWYG editing-views may not display it. This is acceptable as long as another mechanism is provided for modifying that alternative content (e.g., an "Image Properties" dialog).

Examples of Success Criterion B.2.4.1:

• Source content editing-view: In a source content editing-view, alternative content within the source is always available, regardless of what user agents might render. If alternative content is referenced from an external location (e.g., HTML4 longdesc), then that resource can be opened for editing.
• Properties dialog: In a WYSIWYG editing-view, alternative content is not displayed, since the editing-view is designed to mimic typical user agents. However, the alternative content can be accessed and edited via a properties editor that displays the properties for the content that currently has focus.

Related Resources for Success Criterion B.2.4.1:

• Understanding WCAG 2.0, especially the section Understanding "Text Alternatives".

Intent of Success Criterion B.2.4.2:

The intent of this success criterion is to prevent the production of alternative content that is not useful to an end user because it has not been approved by an author and/or it is derived from unreliable sources.

The requirement of author control (a) enables knowledgeable authors to have the final say on alternative content suggested by authoring tools.

The limitation to relevant sources (b) is intended to reduce the possibility that authors who are unfamiliar with accessibility may approve alternative content suggestions without realizing the problems these can cause for end users.

Examples of Success Criterion B.2.4.2:

• Metadata on an archive: A content management system includes a feature that allows authors to make use of images from an extensive photographic archive. The photographic archive includes metadata for each photograph with title and description fields. The title field is always filled, but the description field is sometimes lacking. When authors select an image for insertion, the metadata title is suggested as the alternative text label and the metadata description (if any) is suggested as the long description. In both cases, some basic guidance on what constitutes correct alternative content is provided to help authors judge the appropriateness of the suggestions.
• Alternative content registry: A web page authoring tool implements an alternative content registry (see also Success Criterion B.2.4.4). Since the alternative content was gathered from authors' previous entries into the same fields for the same objects, these are acceptable as relevant sources. The authors are still given the opportunity to accept, modify, or reject the suggested alternative content prior to insertion, in case the non-text content is being used in a different context.
• Accepting patterns: An authoring tool allows authors to accept patterns of future uses of an alternative content under certain conditions (e.g., whenever the same non-text content is marked with the same semantic role).

Related Resources for Success Criterion B.2.4.2:

• Understanding WCAG 2.0, especially the section Understanding "Text Alternatives".

Intent of Success Criterion B.2.4.3:

The intent of this success criterion is to address situations in which authors have either not noticed or ignored opportunities for adding alternative content and have ended their authoring sessions. ATAG 2.0 does not require authoring tools to attempt automated repairs in this situation because doing so risks misleading accessibility checking tools and end users into the assumption that the alternative content was either provided or approved by an author. However, if developers do want to provide automated assistance to end users, then this success criterion specifies what types of repairs may be provided. Essentially:

1. Basic "text" processing repairs using information that is equally available to user agents (e.g., file name, text metadata within non-text objects, the title of a linked resource, etc.) are not allowed, because they are best performed by user agents and assistive technologies.
2. Repairs are allowed when authoring tools have contextual information (e.g., the image is the author's profile picture) that user agents do not have equal access to.
3. Repairs are also allowed that go beyond simple text processing to directly processing images, audio or video. The intent here is to encourage progress in these rapidly advancing fields.

Examples of Success Criterion B.2.4.3:

• Contextual information is known: A social networking authoring tool allows authors to add a description of their profile picture. If an author chooses not to provide a description, the authoring tool labels the image as the author's profile picture.
• Contextual information is not known: A web page authoring tool allows authors to insert images. If an author ignores opportunities to add alternative content and then ends the authoring session, the authoring tool has access to information such as the file name of the image, but since this is text information that is equally available to user agents, it is not suggested.
• Auto-generated transcript: An on-line video editing and hosting authoring tool has a feature that allows authors to create transcripts or captions for their videos. Authors can begin by copying in a transcript if one is available or the authoring tool can use voice recognition technology to generate a transcript for the authors to correct. While this is preferred, the authoring tool also has a setting in which it will automatically add the auto-generated transcript to the published presentation if the end user requests this and the author has not made an attempt to add their own captions or transcript.

Intent of Success Criterion B.2.4.4:

The intent of this success criterion is to ensure that when authors spend effort providing alternative content, this content is retained by the authoring tool in a form that allows it to be easily reused.

Examples of Success Criterion B.2.4.4:

• Alternative content registry: An authoring tool includes a registry that associates object identity information with alternative content (i.e., text, URIs). Whenever an object is used and any alternative content is collected, the object's identifying information and the alternative content is added to the registry. The stored alternative content is suggested as alternative content for author approval whenever the associated object is inserted. The alternative content registry allows several different versions of alternative content to be associated with a single object (e.g., various translations, various contexts).
  Figure: The interface of a sample alternative content registry viewer is shown. The design takes into account multiple non-text content objects of the same name, multiple types of text equivalents for each non-text content 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 "content" to edit. This has brought up a rendering of the "earthrise" image. The viewer also shows that the content 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)
  
• Interoperability with pre-authored content: An enterprise authoring tool's clip art system is integrated with an alternative content registry so that new alternative content created by any author on the enterprise system is stored along with the pre-authored alternative content for the images in the system. The keyword search feature of the clip art system makes use of any alternative content to retrieve matches.

Related Resources for Success Criterion B.2.4.4:

• Understanding WCAG 2.0, especially the section Understanding "Text Alternatives".

Intent of Success Criterion B.2.5.2:

The intent of this success criterion is to reduce the possibility that authors will be forced to use inaccessible templates to create web content because accessible templates do not exist.

Examples of Success Criterion B.2.5.2:

• Variety of accessible templates: A web page authoring tool provides several template choices for home pages, guest books and on-line albums. For each type of functionality, the basic template option is accessible.

Related Resources for Success Criterion B.2.5.2:

• N/A

Intent of Success Criterion B.2.5.4:

The intent of this success criterion is to ensure that authors can easily determine the accessibility status of templates prior to selecting them and that authors are more likely to notice the accessible template options.

Examples of Success Criterion B.2.5.4:

• Template names include accessibility status: In a wiki system, creating a new page brings up a list of available templates. Each template has its WCAG 2.0 conformance level included in its name (e.g., "slide show template - wcagA").
• Sort by accessibility status: A template repository lists the available templates and provides the templates' accessibility status as a sortable field.

Related Resources for Success Criterion B.2.5.4:

• N/A

Intent of Success Criterion B.2.5.5:

The intent of this success criterion is to ensure that new templates that authors create and which might be used by subsequent authors interoperate with the relevant template selection mechanism (See Success Criterion B.2.5.4).

Examples of Success Criterion B.2.5.5:

• Save as template: An authoring tool provides a "save as template" feature. When authors activate this feature, the authoring tool automatically runs an accessibility checker on the template with sample data. Once the checker returns a resulting accessibility status, authors have the option of labeling the template with this status. If the template fails to conform to WCAG 2.0 with sample data, then authors are advised that templates should be held to a high accessibility standard, since they will be repeatedly reused.

Related Resources for Success Criterion B.2.5.5:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.2.5.7:

The intent of this success criterion is to ensure that all templates that the authoring tool provides include an accessibility status, which might be used by a template selection mechanism (See Success Criterion B.2.5.4). This is not a requirement that all templates meet any particular accessibility level.

Examples of Success Criterion B.2.5.7:

• Template repository: A web page authoring tool provides several template choices for home pages, guest books and on-line albums. All of the templates are labeled with an accessibility level (i.e., conforming to WCAG 2.0 Level A, Level AA or Level AAA when used as directed).

Related Resources for Success Criterion B.2.5.7:

• N/A

See Implementing Success Criterion B.2.5.4, substituting "pre-authored content" for "templates".

Intent of Success Criterion B.2.5.8:

The intent of this success criterion is to ensure that all pre-authored content that the authoring tool provides include an accessibility status, which might be used by a pre-authored content selection mechanism (See Success Criterion B.2.5.6). This is not a requirement that all pre-authored content meet any particular accessibility level.

Examples of Success Criterion B.2.5.8:

• Clip art collection: 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 system is interoperable with the alternative content registry, so that whenever authors insert an image from the clip art collection, its alternative content is automatically retrieved.

Related Resources for Success Criterion B.2.5.8:

• See Success Criterion B.2.4.4

Intent of Success Criterion B.2.2.1:

The intent of this success criterion is to ensure that authors are supported in discovering web content accessibility problems in the content that they are editing. This is critical if these issues are to be addressed prior to publishing. The requirement to individually check WCAG 2.0 success criteria is intended to prevent manual checks from being worded in excessively general ways (e.g., "does the page meet all of the requirements?").

The success criterion does not specify how multiple instances of the same problem should be handled, because this will usually depend on the nature of the problem and the degree of automation in the checking and repair features of the authoring tool. Some problems are limited to one or just a few elements and lend themselves to automated or semi-automated reporting of each instance (e.g., missing labels), while other problems extend across many elements and are sometimes best checked globally (e.g., reading level, etc.).

The intent of the note about manual checking is to recognize that the current state of technology does not allow every web content accessibility problem to be identified automatically.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.2.2.1:

• Markup processing checker: An accessibility checking tool includes automated checking for web content accessibility problems that can be detected from markup alone. The tool includes semi-automated checking where potential instances can be detected from the markup, but where the author's assessment of the content is required to make a final decision. In cases where markup processing is of little or no use in detecting problems, manual instructions are included for authors to follow in identifying whether the relevant WCAG 2.0 success criterion has been met.
• Content processing checker: An accessibility checking tool goes beyond markup processing by applying content processing heuristics, such as:
  • Image processing to detect whether foreground and background contrast levels are sufficient or whether images are blank.
  • Text processing to calculate reading levels and detect changes in human language.

Related Resources for Success Criterion B.2.2.1:

• Appendix B: Levels of Checking Automation.
• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.2.2.2:

The intent of this success criterion is to ensure that accessibility checking is an integral part of the normal workflow of authoring tools, similar to checking for other content issues (e.g., spelling, syntax, validation, security). If authors are made aware of the web content accessibility problems in their web content as a normal part of their workflow, the issues are more likely to be repaired before the content is published. Through this process, authors will become more aware of accessible authoring practices.

Examples of Success Criterion B.2.2.2:

• Check-as-you-type: An authoring tool continuously checks the web content being edited and highlights problems as the authors work.
  Figure: A WYSIWYG authoring tool is shown with check-as-you-type accessibility checking activated. Two elements on the page have been highlighted as having problems: an image is surrounded by a blue squiggly line and a line of text is underlined by the same style of blue squiggly line. (Source: mockup by AUWG)
  
  
• Checking on demand: An authoring tool provides accessibility checking from a menu item that is always available.
• Prompt to check before publishing: An authoring tool automatically performs an accessibility check if authors choose a publishing option and informs authors of the results.

Related Resources for Success Criterion B.2.2.2:

• Appendix B: Levels of Checking Automation.

Intent of Success Criterion B.2.2.3:

The intent of this success criterion is to ensure that authors, who in many cases will lack accessibility knowledge, will be able to make adequate judgments. If this is not the case, authors may miss web content accessibility problems that do exist and/or mistakenly identify problems that do not exist.

Examples of Success Criterion B.2.2.3:

• Questions answered: Instructions are formulated to answer the questions: "What part of the content should be examined?" and "What is present or absent that is causing the problem?".
• Variety of views: When author judgment would be enhanced by modified views of the web content being edited, an accessibility browser toolbar is used to provide various previews, such as:
  • an alternative content view (with images and other multimedia replaced by any alternative content)
  • a monochrome view (to test contrast)
  • a text to speech view (to test the availability of text alternatives)
  • no scripts view
  • no frames view
  • no style sheet view
• Judgments saved: An authoring tool saves author judgments for manual checks and only prompts for new judgments after authors have made substantial changes.

Related Resources for Success Criterion B.2.2.3:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.2.2.4:

The intent of this success criterion is to increase the accuracy of author judgments by identifying the location of suspected web content accessibility problems as precisely as possible.

Examples of Success Criterion B.2.2.4:

• By line number: An authoring tool displays potential problems in a separate list by the line number of the first element involved.
• Underlining: A source content editing-view displays potential problems in-line by underlining all of the markup for the affected span of elements.
• Outlining: A WYSIWYG editing-view displays potential problems in-line with the rendered content as blue outlining around the affected span of elements.
• Site-wide checking: A web site management software is designed to identify issues on a site-wide scale (e.g., broken links, outdated information). The software also includes a feature to detect site-wide accessibility problems. The feature is able to identify faulty templates, widgets, etc. that can cause systematic problems.

Related Resources for Success Criterion B.2.2.4:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.2.2.6:

The intent of this success criterion is to ensure that authors are able to obtain an overview of the accessibility status of their web content. This information has many uses, including the assessment of repair options, progress monitoring and performance reporting.

The intent of the note is to be clear that no particular format is required, since this will depend on the nature of the authoring tool and its checking feature.

Examples of Success Criterion B.2.2.6:

• List of accessibility problems: A step-by-step checking feature provides a single consolidated list of all of the web content accessibility problems that were detected. Direct links are provided to additional help and repair assistance for each type of accessibility problem.
• Conformance level report: A check-as-you-type checking feature highlights accessibility problems that can be automatically detected directly within a WYSIWYG editing-view. The author controls the strictness of the automatic checking from a preferences screen, where they select the target WCAG 2.0 level. The overall status of of accessibility checking is available on the application status bar, which lists the target WCAG 2.0 level and the number of outstanding problems that can be automatically detected. A link to the remaining manual checks is also provided.

Related Resources for Success Criterion B.2.2.6:

• N/A

Intent of Success Criterion B.2.2.7:

The intent of this success criterion is to facilitate the creation of accessibility metadata, which can have multiple uses, benefiting both authors (e.g., by enabling interoperability between various checking and repair tools) and end users (e.g., by enabling accessible resource discovery).

The intent of the note is to be clear that no particular format is required. Various metadata options exist and they differ in the nature of the information they encode. The metadata choice will depend on the intended use of the metadata. While this success criterion does not require the use of a particular accessibility metadata format, accessible resource discovery is facilitated by formats that include specific checking results as opposed to formats that only include summary conformance information. The reason for this is that individual end users who are seeking accessible content, may have preferences for certain types of accessibility information (e.g., captions), but not for others (e.g., audio descriptions). This level of detail can be extracted from specific checking results, but not from summary conformance claims.

Examples of Success Criterion B.2.2.7:

• Saving EARL: An authoring tool includes an automated/semi-automated accessibility checker, but only manual repair guidance. In order to give authors additional repair options, the checker includes the option of storing the listing of web content accessibility problems using the Evaluation and Repair Language (EARL). This allows the author to use an external automated/semi-automated repair service.
• Saving AccessForAll: A learning content management system (LCMS) is implemented with a personalized approach to accessibility. Instead of every version of every web content resource being fully conformant (e.g., every video including captions), several versions of each web content resource are produced (e.g., one with captions and one without) and AccessForAll metadata is associated with each. Then when an end user attempts to access a web content resource, their personal preferences are used by the LCMS to locate and serve out the version of the web content resource that is appropriate to that end user's preferences.
• Accessibility of legacy web content: A content management system includes the ability to inventory issues within legacy web content. Running automated checking on legacy web content and storing the results in metadata, provides decision-makers with potentially useful information.

Related Resources for Success Criterion B.2.2.7:

• The IMS AccessForAll Meta-data standard is one way to store the accessibility attributes of web content in order to match them with the preferences of users. This system is also the basis for ISO 24571 (Individualized adaptability and accessibility in e-learning, education and training).
• The Evaluation and Report Language (EARL) is a machine-readable format for expressing test results.
• Google Accessible Search is an example of accessible resource discovery.

Intent of Success Criterion B.2.3.1:

The intent of this success criterion is to ensure that authors are aided in repairing content accessibility problems that are detectable via the authoring tools own checking system.

The intent of the note allowing manual repair assistance to meet this success criterion is to take into account the difficulty of automatically or semi-automatically repairing certain types of accessibility problems.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.2.3.1:

• Check-as-you-type: An authoring tool includes a check-as-you-type feature (see also Example for Success Criterion B.2.2.2) that provides context sensitive repair.
  Figure: A WYSIWYG editing-view is shown, in which a table is being edited. The first row of the table is highlighted in blue "squiggly" lines because a checking heuristic has detected that it might actually be a header row. The author has right clicked on the outlined area and a pop-up menu gives them several repair options: "Repair: Set as header row", "Skip", "Ignore", "Check Accessibility..." and "Help...".
  
• Combined check-repair feature: A WYSIWYG web page authoring tool includes an accessibility check and repair feature that presents web content accessibility problems and repair options in a sequential manner analogous to a typical spelling or grammar checking "wizard". Each screen provides input field(s) for the information required to address the issue as well as additional information and tips that authors may require in order to properly provide the requested information.
  Figure: A correction interface is shown for repairing missing alternate text label for an image. The interface includes (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"). The global checker controls include a progress indicator ("5 of 25") and 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)
  
• Manual repair instructions: For each potential accessibility problem identified by the checking function (as required by Success Criterion B.2.2.1), documentation with repair instructions is provided that authors (with sufficient skill and knowledge to use the rest of the tool) could follow to correct the problem.

Related Resources for Success Criterion B.2.3.1:

• Techniques For Accessibility Evaluation And Repair Tools (AERT)
• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.3.2.1:

The intent of this success criterion is to help ensure that the accessible content support features are perceived by authors (and developers) as a natural and expected part of the authoring tool workflow, just as features for addressing spelling, grammar and syntax errors already are.

Examples of Success Criterion B.3.2.1:

• On by default: A web page authoring tool has all accessible content support features turned on by default within the "Accessibility" tab of its preferences area.
  Figure: The preference setting area of an authoring tool, open to an "Accessibility" section, shows the default settings. "W3C-WCAG" and a level (e.g. "Double-A") are selected as are the following options: "Check accessibility as you type", "Check accessibility after saving", "Auto-correct when possible", "Highlight accessibility related fields", "Prompt when highlighted fields are left blank", and "Provide accessibility 'Quick Tips'". (Source: mockup by AUWG)
  

Related Resources for Success Criterion B.3.2.1:

• N/A

Intent of Success Criterion B.3.2.2:

The intent of this success criterion is to ensure that if authors turn off accessible content support features for any reason, they can easily turn them back on.

Examples of Success Criterion B.3.2.2:

• Toggle in preferences area: A web page authoring tool provides an "Accessibility" tab in its preferences area (See Figure for Success Criterion B.3.2.1, above) where any deactivated features can be reactivated.
• Reminders: An authoring tool has a "wizard"-style accessibility checker and a "check-as-you-type"-style accessibility checker. If the "check-as-you-type"-style checker has been turned off, then authors are reminded about the feature and provided with an option to turn it back on whenever they run the "wizard"-style checker.

Related Resources for Success Criterion B.3.2.2:

• N/A

Intent of Success Criterion B.3.2.3:

The intent of this success criterion is to ensure that if authors attempt to turn off an accessible content support feature for any reason, they will have the opportunity to understand the effect this will have on the accessibility of the web content that they produce.

Examples of Success Criterion B.3.2.3:

• Warning: An authoring tool provides authors with a warning whenever an accessible content support feature is turned off (e.g., from the authoring tool preferences area.
  Figure: 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)
  

Related Resources for Success Criterion B.3.2.3:

• N/A

Intent of Success Criterion B.3.2.4:

The intent of this success criterion is to help ensure that authors are as likely to notice and use functions for addressing accessibility problems as functions for addressing other web content issues (e.g., invalid markup, syntax errors, spelling and grammar errors).

Examples of Success Criterion B.3.2.4:

• Prominence of checking and repair: An authoring tool includes a pane dedicated to content "Evaluation and Repair". The pane lists accessibility, grammar, link checking, spelling, and syntax validation. When the various utilities are run, their results are displayed in similar ways within the pane.
• Prominence of documentation: An authoring tool includes documentation of its accessibility checker as part of the main documentation of an authoring tool, with very similar prominence to that of the spelling-related features.
  Figure: A help system is shown. 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)
  

Related Resources for Success Criterion B.3.2.4:

• N/A

Intent of Success Criterion B.3.4.1:

The intent of this success criterion is to introduce accessible authoring practices as a naturally integrated common practice. The range of examples might include markup fragments, screen shots of WYSIWYG editing-views, sample code or sample applications.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.3.4.1:

• Reference examples are accessible: An HTML authoring tool includes an on-line HTML reference guide. Most of the examples provided in the reference guide conform to WCAG 2.0 Level A.
  
• Screen shots show accessibility features in use: A content management system has a help system that includes screen shots of various screens. When screen shots show examples of the user interfaces while content being produced, the user interface is always such that the content produced would conforms WCAG 2.0 Level A (e.g., prompts filled in, optional accessibility features turned on, etc.).

Related Resources for Success Criterion B.3.4.1:

• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0)

Intent of Success Criterion B.3.3.1:

The intent of this success criterion is to help ensure that authors are able to find help on how to use the accessible content support features effectively.

Examples of Success Criterion B.3.3.1:

• Documentation of accessible content support features: An authoring tool's help system documents the accessible content support features as it would other features of the authoring tool. Since the authoring tool includes context-sensitive help, this is also provided for the accessible content support features.
• Short and long versions of help: During prompting and repairs, an authoring tool provides authors with immediate access to some basic accessibility documentation and one-step access to more comprehensive documentation.
  Figure: An accessibility checker includes some limited tips for authoring short text labels 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 screen shot 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)
  

Related Resources for Success Criterion B.3.3.1:

• N/A

Intent of Success Criterion B.3.3.2:

The intent of this success criterion is to ensure that authors that learn best through tutorials are exposed to accessibility best practices specific to the authoring tool.

Examples of Success Criterion B.3.3.2:

• Accessibility tutorial: A web page authoring tool includes built-in tutorials demonstrating several multi-step tasks (e.g., setting up the folders and files for the local version of a website, formatting with CSS, etc.). One of the tutorials describes how to use the accessible content support features of the authoring tool to increase the accessibility of the web content produced. The tutorial begins at the typical starting point for the tool (e.g., empty document). The tutorial also covers when and how checking and repair should be performed. The tutorial includes some basic rationales for accessible content production. These 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).

Related Resources for Success Criterion B.3.3.2:

• Auxiliary Benefits of Accessibility Features

Intent of Success Criterion A.4.2.2:

The

Examples of Success Criterion A.4.2.2:

• All : An

Related Resources for Success Criterion A.4.2.2:

• N/A