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 more 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 duplication of requirements.

Note: Even when a web-based user interface has met the requirements of WCAG 2.0, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the end-user's user agent, platform, and assistive technology (if any). It is recommended, therefore, that developers of web-based authoring tools be familiar with the accessibility guidance that the User Agent Accessibility Guidelines (UAAG) [UAAG10] provides to the developers of user agents. At the time of publication, UAAG version 1.0 is a W3C Recommendation and version 2.0 is under development.

Examples of Success Criterion A.1.1.1:

• Wiki: 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 includes 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 more accessible to authors with disabilities. Existing platform accessibility guidelines are referenced because accessibility guidelines already exist for many platforms and this wording allows developers the flexibility to conform with accessibility legislation in their markets.

The note regarding documenting the guidelines that were followed in the conformance claim should encourage developers to follow the appropriate guidelines.

Note 1: Developers should refer to the documents listed in the "Related Resources for Success Criterion A.1.2.1" section. Unless special 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. Several general software accessibility guidelines are also referenced. It is acceptable to follow one of these sources of general guidance, and in most cases, the techniques for implementing the general guidance on a platform will entail following the same platform accessibility guidelines.

Note 2: Even when a non-web-based user interface has followed the relevant user interface accessibility guidelines for the platform, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the platform and assistive technology (if any).

Examples of Success Criterion A.1.2.1:

• Mobile authoring tool: The developer of an authoring tool app for the iPhone platform follows the guidance provided in the "Accessibility Programming Guide for iPhone OS".

Related Resources for Success Criterion A.1.2.1:

• The following is a non-exhaustive list of accessibility guidelines for various platforms (for additional information related to keyboard shortcuts on various platforms, see the Related Resources for Success Criterion A.3.1.3):
  • Desktop OS
    • GNOME Desktop on Linux: GNOME Accessibility Developers Guide
    • KDE Desktop on Linux: Developer's Information
    • Mac OS: Accessibility Overview (may require account)
    • Microsoft Windows: Accessibility Overview
  • Mobile OS
    • Android: Android Developers: Designing for Accessibility
    • BlackBerry: BlackBerry Accessibility
    • iPhone OS: Accessibility Programming Guide for iPhone OS (may require account)
  • Cross-OS environments
    • Eclipse: Designing Accessible Plug-ins in Eclipse
    • Java SE: Java SE Desktop Accessibility
    • Lotus Notes: Lotus Notes Checklist
• The following is a non-exhaustive list of general software accessibility guidelines:
  • ISO 9241-171:2008 Ergonomics of human-system interaction - Part 171: Guidance on software accessibility
  • Software Checklist (IBM)
  • Section 508 §1194.21 Software applications and operating systems
  • The WAI International Policies Relating to Web Accessibility resource includes links to various international legislation and other policies that may include applicable accessibility guidelines for non-web-based functionality.

Intent of Success Criterion A.1.2.2:

The intent of this success criterion is to ensure that authoring tool user interfaces that are not web applications are more accessible to authors with disabilities who use assistive technologies that communicate with software via platform accessibility services. The requirement is stated generally because the specifics of what constitutes a platform accessibility service will differ on each platform.

The note regarding documenting the platform accessibility service(s) that were implemented in the conformance claim should encourage developers to implement services that are well supported by assistive technologies.

Note: Even when a non-web-based user interface has been designed to expose accessibility information through platform accessibility services, many factors will determine the accessibility of any particular end-user's experience, including (but not limited to): the features and settings of the platform and assistive technology (if any).

Examples of Success Criterion A.1.2.2:

• WYSIWYG editor 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. The conformance claim includes links to the Accessibility Programming Guidelines for Cocoa.
  
• Content management system on Windows: Content management system on Windows: A content management system is written to operate on the Windows operating systems following Microsoft Windows' accessibility API, UI Automation, Microsoft Active Accessibility, or IAccessible2. The conformance claim includes links to the applicable Microsoft Developer Network documents.

Related Resources for Success Criterion A.1.2.2:

• The following is a non-exhaustive list of documents related to communication with platform accessibility services for various platforms:
  • Desktop OS
    • GNOME Desktop on Linux: GNOME Accessibility Developers Guide
    • KDE Desktop on Linux: Developer's Information
    • Mac OS: Accessibility Overview (may require account)
    • Microsoft Windows: Accessibility Overview
  • Mobile OS
    • Android: Example from Android Developer Reference
    • BlackBerry: BlackBerry Accessibility
    • iPhone OS: Accessibility Programming Guide for iPhone OS (may require account)
  • Cross-OS environments
    • Java SE: Java SE Desktop Accessibility

Intent of Success Criterion A.2.1.1:

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

The term "programmatically associated" is used to take into account that text alternatives may sometimes appear within web content in ways that authoring tools are not able to detect (e.g. when the information conveyed by an image is described in an adjacent paragraph without the relationship appearing in the markup).

Examples of Success Criterion A.2.1.1:

• Non-web-based editor: If an image in the content being edited includes alternative text, this is exposed to assistive technologies via the platform accessibility service.
• Web-based editor: If an image in the content being edited includes alternative text, this is included in the markup of the editing-view, so that the alternative text will be made available to the user agent.

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 WCAG 2.0 Guideline 1.1 and the section Understanding "Text Alternatives".

Intent of Success Criterion A.2.1.2:

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

There are two ways to meet this success criterion:

• Option (a) is to render the alternatives in conjunction with the rendered time-based content within the authoring tool's editing-view. For example, a captioned video would have its captions displayed when it played. This approach is preferable, since it does not require authors to switch applications.
• Option (b) is to instead provide authors with the option of rendering their content in a user agent that is able to render the alternatives. While this is not ideal from a usability perspective, it is necessary because alternatives are sometimes provided in different modalities that authoring tools are not equipped to render. For example, an audio editor might allow authors to edit the waveform of the audio file and render (i.e. play) the resulting audio files. However, the audio editor might not be equipped to render video, so if an audio file includes an alternative that is a sign language file in video format, the audio editor will need assistance in rendering the file.

Examples of Success Criterion A.2.1.2:

• Web-based WYSIWYG: A web-based WYSIWYG editing-view is implemented so that videos placed into the content are rendered. If the videos include captions these are displayed, meeting (a).
• Audio editor: An audio editor allows authors to edit audio tracks using the audio waveform. At any time, authors can play the audio file. Sometimes the audio files include a link to a video file that contains an alternative version (e.g. sign language). Although the audio editor does not include the functionality to natively render the video, it provides the option to launch the video in a user agent specified by the author, meeting (b).

Related Resources for Success Criterion A.2.1.2:

• User Agent Accessibility Guidelines (UAAG) 1.0.
• WCAG 2.0 (including Understanding WCAG 2.0 and How to Meet WCAG 2.0), especially WCAG 2.0 Guideline 1.2.

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 status messages to authors, then authors with disabilities will have the same access to the status messages as other authors.

The note provides some examples of status indicators that are relatively common in authoring tools. For example, many WYSIWYG editors include an option to display an icon to indicate the location of anchor tags and comments, both of which would otherwise be hidden from view. Another common status indicator is underlining spelling errors in red.

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 WCAG 2.0 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 when this information is already made available to other authors by editing-views. This is important because this type of rendering acts as a type of preview to help authors understand how their content may appear to end users, once it is published. Authors who cannot see also need to understand how their web content will be experienced by end users who can see.

Note: This success criterion pertains to the rendered properties of text on the screen, even if the properties differ from the content being edited (e.g. when authors chose custom display settings as per Success Criterion A.3.6.1). In this way, the views provided on screen and via any assistive technologies can remain synchronized.

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 service. Included in the information passed to the platform accessibility service is information on the size, font, foreground, 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 then passes it on to the appropriate platform accessibility service. The user agent would be cited in any conformance claim.

Related Resources for Success Criterion A.2.2.2:

• N/A

Intent of Success Criterion A.3.1.1 (Based on WCAG 2.0, Success Criterion 2.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 that relates to authoring web content properties that contain 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 would not be exempt. Finally, this is a Level A exception only. There is no exception for the Level AAA requirement (Success Criterion A.3.1.4).

Note 1 clarifies that the success criterion does not require a hardware keyboard to be present. Many mobile platforms lack hardware keyboards, but nonetheless provide "keyboard interfaces".

Note 2 clarifies that the exception applies to the underlying function and that pointing device input variables, such as pressure, speed and angle, are also covered.

Note 3 clarifies that rather than replacing other types of interaction, the keyboard access requirement is to provide an alternative.

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.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). 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 pages include 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). 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.
• Touchscreen: An authoring tool designed to be used on a touchscreen-equipped device based
  

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 WCAG 20 Success Criterion 2.1.1.

Intent of Success Criterion A.3.1.2 (Modified from WCAG 2.0, Success Criterion 2.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.

The case of keyboard traps in rendered content within an editing-view (e.g. WYSIWYG) is the more challenging because authors may open content for editing that violate the WCAG 2.0 requirement against keyboard traps in content. The success criterion requires authoring tools to handle these cases.

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 for editing 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 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 would be 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 WCAG 2.0 Success Criterion 2.1.2.

Intent of Success Criterion A.3.1.3:

The intent of this success criterion is to introduce a Level AA requirement to strengthen the requirement of Success Criterion A.3.1.1. That success criterion would be met even by a keyboard access mechanism in which users had to sequentially navigate through every available user interface component in order to reach their intended destination. This success criterion (A.3.1.3) introduces the additional requirement that keyboard access must include mechanisms to make it more efficient that this type of purely sequential keyboard access.

The wording is intentionally general because the appropriate mechanisms available for increasing the efficiency of keyboard access vary according to the operating environment and the design of the authoring tool:

1. In desktop environments with a full keyboard, there is generally some set of keys available for developers to use as shortcut keys that directly link to particular functionality (e.g. the "ctrl" + "S" key combination can be directly mapped to the "Save" function).
2. In web-based environments very few direct shortcut keys are available, once the potential keys used by the various operating systems, user agents, and assistive technologies are taken into account. In this case, bypass links are useful mechanisms for making keyboard access more efficient.
3. In mobile environments, the situation is variable. Some mobile environments include physical keyboards and support keyboard shortcuts. Other mobile environments do not enable keyboard shortcuts, but often increase keyboard navigation efficiency via recommending the use of tabs and other organizational mechanisms.

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 (e.g. for open document, save document, cut, copy, paste).
• 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 WAI-ARIA landmarks (e.g. banner, main, navigation, search) to allow authors to navigate more quickly.

Related Resources for Success Criterion A.3.1.3:

• The following is a non-exhaustive list of keyboard shortcut conventions for various platforms:
  • Desktop OS
    • GNOME Desktop on Linux: GNOME Human Interface Guidelines 3.4 - Keyboard Interaction
    • Mac OS: Mac OS X keyboard shortcuts
    • Microsoft Windows: Keyboard Shortcuts for Windows
  • Mobile OS
    • BlackBerry: UI Guidelines - BlackBerry Smartphones - Best practice: Implementing shortcut keys
  • Cross-OS environments
    • 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

Intent of Success Criterion A.3.1.4 (Based on WCAG 2.0, Success Criterion 2.1.3):

The intent of this success criterion is to establish an enhanced requirement for keyboard access at Level AAA, 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 on platforms that support keyboard commands have the ability to remap the authoring tool's default keyboard shortcuts in order to avoid keystroke conflicts, use familiar keystroke combinations and optimize keyboard layout (e.g. for one-handed use).

This success criterion only applies to keyboard commands provided by the authoring tool, not keyboard commands provided by the platform on which the authoring tool is based.

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 on platforms that support keyboard commands 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: An authoring tool on Windows includes a feature that allows authors to press a modifier key (e.g. the "Alt" key) to display all of the keyboard shortcuts in the current authoring tool user interface on top of the components to which they relate.

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:

• No time limits: An authoring tool does not include any time limits.
• Save and continue: A web-based content management system automatically logs the author out after 15 minutes of inactivity. Five minutes before this occurs a "Save and Continue" button is displayed to the author.
• 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 (Based on WCAG 2.0, Success Criterion 2.2.1):

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:

• No time limits: An authoring tool does not include any time limits.
• 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 WCAG 2.0 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 either fast reactions (i.e. to click on an object in motion) or the ability to track movement.

Examples of Success Criterion A.3.2.3:

• No moving user interface controls: An authoring tool does not include any moving user interface controls.
• 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 WCAG 2.0 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 visual time-based web content (e.g. animations) 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. Once playing, a pause button is always available.
• 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. Once playing, a pause button is always available.

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 WCAG 2.0 Guideline 2.3.

Intent of Success Criterion A.3.4.1:

The intent of this success criterion is to help authors using keyboard interfaces to navigate more efficiently using the structure of the web content being edited in cases where that structure is already exposed to the author.

Examples of Success Criterion A.3.4.1:

• Source editing-view: A source editing-view supports authors by providing the ability to use keyboard shortcuts to select the current element (e.g. table row) and other keyboard shortcuts to move the focus 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 headings: 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>...<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.
  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: mock up 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.
• 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> elements), and any content, such as text or images, 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 effect 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 keyboard interfaces to navigate more efficiently using the programmatic relationships that may exist in many types of web content.

Examples of Success Criterion A.3.4.2:

• JavaScript editor: When a method is used, authors can navigate directly to where that method is defined.
• HTML/CSS editor: When a style is used in content being edited, authors can navigate directly to where that style is defined, even if an external style sheet must be opened.
• HTML editor: When an id is used in content being edited, authors can navigate directly to where that id is defined.
• WAI-ARIA editor: Authors can navigate directly via WAI-ARIA relationships, such as aria-labeledby and aria-describedby.

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.

Examples of Success Criterion A.3.5.1:

• Basic text search: An authoring tool provides both WYSIWYG and source editing-views. The authoring tool provides two-way 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 searching for plain text sequences within textual metadata fields (e.g. title, description, and author fields).

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 rendering 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). 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 style sheet 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 would be 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 re-entered at the beginning of 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 unless the author has specifically selected different settings at the level of the authoring tool. 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.

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:

• For web-based authoring tools, see Related Resources for Success Criteria A.1.1.1.
• For non-web-based authoring tools, see Related Resources for Success Criterion A.1.2.1.

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 a more 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) used in the market. 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 an in-market user agent.

There are two ways to meet this success criterion:

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

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

Note: Developers may create a preview feature 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, meeting (a).
• 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, meeting (a).
• 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, meeting (a).
• 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", meeting (b).

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 an enhanced Level AAA requirement for preview features, in which authors have the flexibility to choose their preferred user agent for performing previews.

Examples of Success Criterion A.3.7.2:

• Non-web-based authoring tool: A non-web-based authoring tool gives authors the option of choosing from any of the user agents installed on their computer to perform the preview.
• Web-based authoring tool: A web-based authoring tool provides authors with a URI that can be entered into another user agent 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, but people with some disabilities have more difficulty creating error-free input.

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. Firstly, text entry actions in text fields can be reversed using the "Undo" feature of the user agent. Secondly, "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). The user agent would be cited in any conformance claim.

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 WCAG 2.0 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. The success criterion, therefore, requires that mechanisms for changing settings can also be used by authors to return the settings to their original values or, if the setting is not reversible with the same mechanism, the author will have had to confirm the setting. Everyone makes mistakes, but people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for some people with disabilities to detect that they have made an error.

Examples of Success Criterion A.4.1.2:

• 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.
• Upgrade confirmation: An authoring tool has a setting that allows the author to upgrade to the newest version free of charge. However, once the upgrade is made it will not be possible to reverse the installer for the previous version is no longer available. When the author selects the setting, they receive a warning that the upgrade will not be reversible and they must confirm that they wish to upgrade.

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 establish an enhanced Level AAA requirement for reversing inadvertent actions that modify the content being edited. Everyone makes mistakes, but some people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for some people with disabilities to detect and rectify errors, so it is more likely that they will benefit from the ability to reverse a series of actions once an error is discovered.

The note makes it clear that this success criterion does not require authoring actions made in one authoring session to be reversible in subsequent authoring sessions.

Examples of Success Criterion A.4.1.3:

• Undo queue: An authoring tool saves author actions in a "last-in-last-out" queue.

Related Resources for Success Criterion A.4.1.3:

• 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 descriptions of how to use the features. These descriptions can be provided in the documentation or user interface of the authoring tool or by the underlying platform, if the feature is in fact a service of that platform.

The note is a reminder 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 in content
  • 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 find descriptions of the authoring tool's features. These descriptions can be provided in the documentation or user interface of the authoring tool or by the underlying platform, if the feature is in fact a service of that platform.

The note is a reminder 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 available features. The documentation conforms to WCAG 2.0 Level A.

Related Resources for Success Criterion A.4.2.2:

• "Software Documentation" on Wikipedia

Intent of Success Criterion B.1.1.1:

The intent of this success criterion is to ensure that when authoring tools have been designed to generate web content that is published directly to end users without an opportunity for author action, the default option should be for that web content to be accessible (WCAG).

The note acknowledges that there are automatic behaviors that may be specified by other parties and that author actions may purposefully or inadvertently affect the accessibility of the content generated later.

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

Examples of Success Criterion B.1.1.1:

• No automatic content generation after authoring sessions: An authoring tool only makes edits to content as directed by the author when the content file is open for authoring (i.e. during an authoring session)
• Email archive: An automatic email archiving system automatically creates web pages from each email message that it receives. It has been designed to generate accessible markup, but if email messages contain accessibility problems, the archiving system is not able to rectify them.
• Social networking application: A social networking application collects some limited information from authors (e.g. name, gender, status updates), which the application uses to personalize an automatically-generated web application that meets the requirements of WCAG.

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

The intent of this success criterion is to provide more flexible developer guidance in cases where authors are available to assist in increasing the accessibility of content. The guidance recognizes that authors may often not be able to assist, if they are not made aware that web content accessibility problems do or may exist.

Note 1 highlights the fact that when an authoring tool automatically selects a template for the author to use, the authoring tool is considered to be auto-generating the content in the template.

Note 2 acknowledges that there are many ways in which the automatic behavior of authoring tools can be modified that are not under the control of the developer.

There are four ways to meet this success criterion:

Option (a) is the most straightforward. It requires the authoring tool to generate only accessible content.

Option (b) takes into account that even more access-aware authoring tools may need to query the author regarding issues that require human judgment, such as whether alternative text is suited to the context.

Option (c) takes into account that prompting during the generation process may be contrary to the workflow. Instead, the authoring tool can run a checker on the output.

Option (d) is similar to (c) but takes into account that ATAG 2.0 allows the option of manual checking.

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

Examples of Success Criterion B.1.1.2:

• 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) 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), meeting (a).
• 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, meeting (b).
• Automatic accessibility checking: An authoring tool allows images, videos, and other multimedia files to be dragged into documents. When this happens, markup is automatically-generated that contains accessibility problems. However, the authoring tool includes an "as-you-type" accessibility checker that unobtrusively highlights the problems for author attention, meeting (c).
• Manual accessibility checking: An authoring tool allows images, videos, and other multimedia files to be dragged into documents. When this happens, markup is automatically-generated that contains accessibility problems. Since the authoring tool includes a manual checking wizard instead of an automatic checker, a message appears in a status area of the user interface stating that the author should use the wizard before publishing, meeting (d).
• 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.1.2:

• 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 encourage authoring tools to preserve accessibility information (WCAG) during restructuring or recoding transformations and to ensure that authors are made aware when 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 example 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 negative connotation intended here. In some cases, the number of source technology possibilities is simply too large to ensure that complete mappings are in place for all of them.

The options available partially mirror the options for Success Criterion B.1.1.2, reflecting the similarities between automatic generation and restructuring/re-coding web content transformations:

Option (a) is the most straightforward. It requires the authoring tool to preserve accessibility information during transformations.

Option (b) is to warn the author directly that accessibility information may be lost, allowing them to decide whether or not to proceed.

Option (c) takes into account that prompting during the transformation process may be contrary to the workflow. Instead, the authoring tool can run a checker on the output.

Option (d) is similar to (c) but takes into account that ATAG 2.0 allows the option of manual checking.

ATAG 2.0 identifies other types of transformations in which the expectation for preserving accessibility information is higher. These are optimizing transformations (Success Criterion B.1.2.3) and transformations in which non-text content is preserved (Success Criterion B.1.2.4).

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: A "Save As" feature preserves accessibility information in similar data structures, meeting (a). 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: A "Save As" feature preserves accessibility information in a dissimilar, but accessible way, when similar data structures are not available, meeting (a). 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) are retained as rendered text content with two-way linking.
• Warning when text is converted to graphics): 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, meeting (b).
• Option to cancel: A markup editor has a feature 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 author has the option to cancel the operation, in which case the content will not be opened for editing, meeting (b).
• Automatic accessibility checking: An authoring tool allows content to be imported from another format. When this happens, the source content is recoded into the technology of the current document. While accessibility was considered in the design of the feature, web content accessibility problems may still occur. However, the authoring tool includes an "as-you-type" accessibility checker, meeting (c).
• Manual accessibility checking: An authoring tool allows content to be imported from another format. When this happens, the source content is recoded into the technology of the current document. While accessibility was considered in the design of the feature, web content accessibility problems may still occur. Since the authoring tool includes a manual checking wizard instead of an automatic checker, a message appears in a status area of the user interface stating that the author should use the wizard before publishing, meeting (d).

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 encourage authoring tools to preserve accessibility information during copy-paste operations. Due to differences in how data is encoded by different applications and the differences between clipboard mechanisms on various platforms, the wording is limited to the case in which both the copy and paste sides of the operation are performed by the same authoring tool. The wording also excludes cases in which documents

However, on platforms with clipboard mechanisms that support structured web content, as many do, it is likely that implementation of this success criterion by multiple authoring tools will also increase the probability of accessibility information being preserved during copy-paste operations between different authoring tools.

The wording of the success criterion does not require that all structured content be preserved, as this can sometimes raise security issues, especially when the copy source is another site.

Examples of Success Criterion B.1.2.2:

• Plain text clipboard format: A WYSIWYG HTML authoring tool is running on a platform that only provides a plain text clipboard. On copy, the authoring tool places markup, including any textual accessibility information, directly into clipboard as a block of text. On paste, the text is then parsed and placed back into the document, including any accessibility information, and rendered for the author.
• HTML clipboard format: A WYSIWYG HTML authoring tool is running on a platform that provides an HTML clipboard format. On copy, the authoring tool converts its internal document representation into HTML and places that on the clipboard, including any accessibility information. On paste, the markup is then parsed and placed back into the document, including any accessibility information, and rendered for the author.

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

The intent of this success criterion is to ensure that web content transformations intended only to optimize content do not result in the introduction of web content accessibility problems.

Examples of Success Criterion B.1.2.2:

• Pretty-print: A "pretty-print" tool reformats markup code to make it easier to read by programmers. The tool never makes changes to the markup tags.
• Video compression: A tool that compresses video does not automatically delete text tracks or secondary audio tracks, since these may contain accessibility information.

Related Resources for Success Criterion B.1.2.3:

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

Intent of Success Criterion B.1.2.4:

The intent of this success criterion is to increase the likelihood that text alternatives will be preserved by web content transformations. This is especially important because text alternatives, such as labels and long descriptions, can represent substantial investments of author effort.

Examples of Success Criterion B.1.2.4:

• Save as HTML: A word processor includes a "Save as Simple HTML" feature that recodes word processor files into HTML where there is a one-to-one correspondence between elements. As a result, some word processor-specific content is lost (e.g. change tracking, footnotes). However, because of the existence of the <img> element in HTML, images are preserved and, in order to meet this success criterion, the text alternatives associated with the image are also preserved in HTML.

Related Resources for Success Criterion B.1.2.4:

• 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 ensure that authors who have the motivation and knowledge to create more accessible web content using an authoring tool are not prevented from doing so by restrictions in the actions that the authoring tool allows them to perform. The subsequent success criteria in Part B will build on this minimal requirement.

Note that the term "restricted" is not intended to have any negative connotation. Authoring tools usually restrict web content authoring in order to simplify the production of content that is in fact complex and technical. The accessibility implications of the restrictions may be positive or negative and need to be considered case by case:

Examples of unrestricted authoring:

1. source code editor: authors can type whatever they like (e.g. <img src="..." alt="..." longdesc="..." />)
2. WYSIWYG editor for HTML4: the "Insert Image" dialog includes all of the HTML4 attributes for <img>.

Examples of restricted authoring that does not prevent WCAG 2.0 success criteria from being met:

1. WYSIWYG editor for HTML4: the "Insert Image" dialog includes just some of the HTML4 attributes for <img>, but alt and longdesc are included in the subset.
2. CMS: authors can only add images that they have previously uploaded to their "Asset Manager". While alternate text and long description do not appear as options when they choose images from the "Asset Manager" to include on a page, they can add/edit these values at any time within the "Asset Manager".

Examples of restricted authoring that prevents WCAG 2.0 success criteria from being met:

1. WYSIWYG editor for HTML4: the "Insert Image" dialog has only one field "source". There is no possible way to add other attribute values, including for the alt and longdesc attributes.
2. CMS: to be saved, each page of content must have a main title, but when the author provides text for the title it is marked up with presentation markup rather than appropriate header markup.

Unrestricted authoring tools entail less author guidance and therefore may allow the introduction of more accessibility problems than authoring tools with restrictions that encourage accessibility. ATAG 2.0 addresses this issue with other success criteria, including B.3.1.1 Checking Assistance (WCAG), which requires an accessibility checking feature.

Restrictions on authors may also be related to automatically-generated content. ATAG 2.0 addresses the accessibility of automatically-generated content in Guideline B.1.1: Ensure that automatically-specified content is accessible.

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

Examples of Success Criterion B.2.1.1:

• No restrictions (source content editing-view): An authoring tool is designed around a source editing-view, allowing motivated and knowledgeable authors to control every detail of the content produced, including following accessible authoring practices.
• Accessible workflow exists: An authoring tool is designed such that accessible web content (in this case 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;
  • correctly follow all prompts by features that support the production of accessible content;
  • uses the accessibility checker, including a final check prior to publishing;
  • 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.

Related Resources for Success Criterion B.2.1.1:

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

Intent of Success Criterion B.2.2.1:

The intent of this success criterion is to help ensure that accessible authoring practices are part of the default workflow of authoring tools. This requirement applies when the authoring outcome is predictable by the authoring tool. For example, a generic "insert table" command would not be applicable, despite the fact that an author might misuse it for layout, because the author might be seeking the outcome of adding tabular information. In contrast, a page layout editor is covered by the requirement because the purpose of the feature is to edit the page layout.

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

Examples of Success Criterion B.2.2.1:

• Structural markup: A WYSIWYG HTML editor does not include any authoring action options that will necessarily result in web content that will not meet the WCAG 2.0 Level A success criteria. For example:
  • a toolbar button that allows text to be marked as bold does so by adding a <strong> element rather than a <span> element with a bold style.
  • a the toolbar button for placing text into a bulleted list does so with list markup (e.g. <ul> and <li> elements) rather than a <span> element-based implementation.
  • a page layout view makes use of CSS positioning rather than table markup.
• 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 positions.
  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: mock up by AUWG)
  

Related Resources for Success Criterion B.2.2.1:

• 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 if authoring tools provide authors with content authoring support that goes beyond source editing (e.g. property dialogs) then accessibility information that is required for the content are similarly supported. In many cases, authoring tools support a subset of all of the possible properties that technologies might offer. This success criterion requires that the subset of supported properties must include properties required for conformance to WCAG 2.0.

The note is a reminder that the mechanisms for adding accessibility information properties must have prominence that is at least comparable with the other mechanisms for other properties.

Examples of Success Criterion B.2.2.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: mock up by AUWG)
  
• 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.2.2:

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