Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0

Abstract

This document provides non-normative information to authoring tool developers who wish to satisfy the guidelines in the "Authoring Tool Accessibility Guidelines 2.0" [ATAG20]. It includes suggested techniques, sample strategies in deployed tools, and references to other accessibility resources (such as platform-specific software accessibility guidelines) that provide additional information on how a tool may satisfy each ATAG 2.0 guideline.

The "Authoring Tool Accessibility Guidelines 2.0" (ATAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative (WAI).

Introduction

This is a Working Draft of the Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0. While the Authoring Tool Accessibility Guidelines 2.0 [ATAG20] provides a generic description of the requirements for authoring tools that are accessible to people with disabilities, these implementation techniques provide an interpretation of the guidelines as they apply to real tools. This interpretation represents the best thinking of the Authoring Tool Accessibility Guidelines Working Group (AUWG) and as such is a good guide to achieve conformance to ATAG 2.0. The Working Group encourages developers to implement these techniques where appropriate. However, these techniques do not provide a final definition of ATAG 2.0 conformance and it is possible to meet the guideline requirements without following these techniques and thus this document is informative. As new methods of conforming to the guidelines come to the attention of the Working Group, these techniques will be updated.

Definition of authoring tool

This section is included here for informative purposes. The normative version appears in the Authoring Tool Accessibility Guidelines 2.0 [ATAG20].

ATAG 2.0 defines an "authoring tool" as any software, or collection of software components, that authors can use to create or modify Web content for use by other people.

This definition can cover components such as :

content management systems, courseware tools, content aggregators
site management tools
WYSIWYG editors, plain text editors (embedded and stand-alone)
conversion tools, productivity software that can output Web content technologies (e.g., "Save as HTML")
blogging tools, wikis, online forums, emailers that produce Web-content
multimedia authoring tools
scripting tools, widget development environment
etc.

Note: Synchronous tools (e.g., chats, collaboration tools, whiteboards, etc.), especially those that archive as Web content, are considered authoring tools and can be made more accessible for both participants and users of the stored archives. While not all parts of ATAG 2.0 will usefully apply, some Techniques for Real-Time Content Production are available.

Components of Web Accessibility

Authoring tools are just one aspect of accessibility. For an overview of the different components of accessibility and how they work together see:

Essential Components of Web Accessibility - Explains how the WAI guidelines work together with assistive technologies to provide access to the Web by people with disabilities.
Web Content Accessibility Guidelines (WCAG) Overview - Introduces guidelines on making Web content accessible.
User Agent Accessibility Guidelines (UAAG) Overview - Introduces guidelines on the design of accessible browsers and other user agents.

Organization of the ATAG 2.0 Document

Two Parts

ATAG 2.0 is divided into two parts, each reflecting a key aspect of accessible authoring tools. Part A includes principles and associated guidelines that are related to ensuring accessibility of the authoring tool user interface to authors with disabilities. Part B contains principles and guidelines related to ensuring support by authoring tools for the creation of accessible Web content by any author (not just those with disabilities) to end users with disabilities.

Part A: Make the authoring tool user interface accessible

The guidelines and success criteria in Part A are organized around the following four principles, adapted from the four principles in WCAG 2.0:

Authoring tool must facilitate access by assistive technology - Assistive technologies can only provide augmented display and control to their users if the relevant information is made available by authoring tools using common protocols.
Authoring tool must be perceivable - Authors with a wide range of abilities must be able to perceive its user interface components.
Authoring tool must be operable - Authors with a wide range of abilities must be able to operate its user interface components.
Authoring tool must be understandable - Authors with a wide range of abilities must be able to understand the user interface components that they can perceive and operate.

Part B: Support the production of accessible content

There are three principles in Part B:

Production of accessible content must be enabled - The creation of accessible content is dependent on the combined actions of the authoring tool and the author. This guideline specifies the responsibilities that rest exclusively with the tool.
Authors must be supported in the production of accessible content - Actions may be taken at the author's initiative that may result in accessibility problems. The authoring tool should include features that provide support and guidance to authors in these situations, so that accessible authoring practices can be followed and accessible web content can be produced.
Accessibility solutions must be promoted and integrated - This guideline includes guidelines that require authoring tools to raise the profile of accessible authoring practices, while at the same time, integrating functions related to accessibility in order to encourage authors to make them common practice.

Note: While the requirements in Part B do not deal with the accessibility of the authoring tool user interface, it should be noted that any of the features (e.g., checker, tutorial) added to meet Part B success criteria must also meet the user interface accessibility requirements of Part A.

Success Criteria

Under each guideline there are success criteria that describe specifically what must be achieved in order to conform . They are similar to the "checkpoints" in ATAG 1.0. Each success criterion is written as a statement that will be either true or false when a specific authoring tool is tested against it.

All ATAG 2.0 success criteria are written to be testable. While some can be tested by software, others require human testers for part or all of the test.

Each success criterion for a guideline has a link to the Techniques document that provides:

"sufficient techniques" for meeting the success criterion, and
optional "advisory techniques".

Success Criteria Levels

ATAG 2.0 success criteria are organized into three levels of conformance.

Level A:
- For success criteria in Part A:
  - These success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on tool design. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access tools in different ways.
- For success criteria in Part B:
  - A basic level of support to all authors in creating Web content
  - The content accessibility target is Level "A" Web content accessibility.
Level AA:
- For success criteria in Part A:
  - These success criteria provide additional support for assistive technology. At the same time, they also support more direct access to content by the many people who use authoring tools without assistive technology. In general, Level AA success criteria place more limits on tool design than Level A success criteria in Level.
- For success criteria in Part B:
  - An intermediate level of support to all authors in creating Web content
  - The content accessibility target is raised to Level "AA" Web content accessibility.
Level AAA:
- For success criteria in Part A:
  - These success criteria increase both direct access and access through assistive technology. They place even tighter limits on tool design.
- For success criteria in Part B:
  - An advanced level of support to all authors in creating accessible Web content.
  - The content accessibility target is raised to Level "AAA" Web content accessibility.

Note: If a guideline success criterion is not applicable to an authoring tool, then that success criterion is treated as satisfied for conformance purposes as long as a rationale is provided.

Implementation Techniques

The techniques are informative (i.e., non-normative).

The list of techniques for each success criteria are not exhaustive. Rather, these techniques represent an illustrative sampling of approaches. There may be many other ways a tool might be designed and still meet the normative criteria contained in the success criteria.

Some techniques are labeled as "[Sufficient]". These techniques are judged by the Working Group to meet the success criteria to which they apply. Conditional wording may limit the applicability of any given sufficient technique to a particular type of content or authoring tool. Inclusion does not imply that the description will be verified or is verifiable. When multiple techniques must be implemented together to be sufficient, they are labeled "[Sufficient in combination]".

Some techniques are labeled as "[Advisory]". These techniques are included as additional information.

Note: Use of "mock" screenshots is for general illustrative purposes only. They do not imply endorsement of similar tools by the Working Group or suggests that these screenshots represent the best or only implementations.

Levels of Conformance

Authoring tools may claim full conformance to ATAG 2.0 at one of three conformance levels. The level achieved depends on the level of the success criteria that have been satisfied. The full conformance levels are:

Full ATAG 2.0 Conformance at Level "A"
The authoring tool satisfies all of the Level A success criteria.
Full ATAG 2.0 Conformance at Level "Double-A"
The authoring tool satisfies all of the Level A and Level AA success criteria.
Full ATAG 2.0 Conformance at Level "Triple-A"
The authoring tool satisfies all of the success criteria.

In addition, a Partial Conformance claim option is available in cases where an authoring tool has satisfied all of the success criteria at a specified level in one of the two Parts of the document (i.e. "Part A: Make the authoring tool user interface accessible" and "Part B: Support the production of accessible content"). The partial conformance levels are:

Partial ATAG 2.0 Conformance Level "A": Authoring Tool User Interface
The authoring tool satisfies all of the Level A success criteria in Part A. Nothing is claimed about Part B.
Partial ATAG 2.0 Conformance Level "Double-A": Authoring Tool User Interface
The authoring tool satisfies all of the Level A and Level AA success criteria in Part A. Nothing is claimed about Part B.
Partial ATAG 2.0 Conformance Level "Triple-A": Authoring Tool User Interface
The authoring tool satisfies all of the success criteria in Part A. Nothing is claimed about Part B.
Partial ATAG 2.0 Conformance Level "A": Content Production"
The authoring tool satisfies all of the Level A success criteria in Part B. Nothing is claimed about Part A.
Partial ATAG 2.0 Conformance Level "Double-A": Content Production"
The authoring tool satisfies all of the Level A and Level AA success criteria in Part B. Nothing is claimed about Part A.
Partial ATAG 2.0 Conformance Level "Triple-A": Content Production"
The authoring tool satisfies all of the success criteria in Part B. Nothing is claimed about Part A.

Note: The Working Group remains committed to the guiding principle that: "Everyone should have the ability to create and access Web content". Therefore, it is recommended that Partial Conformance be claimed as a step towards full conformance.

Relationship to the Web Content Accessibility Guidelines (WCAG)

The ATAG 2.0 conformance model relies upon Web Content Accessibility "Benchmark" documents to precisely specify what an evaluator interprets "Accessible Web Content" to mean for the particular Web content technologies that an authoring tool produces and is implemented using (if applicable).

The recommended reference for the Web Content Accessibility "Benchmark" is the W3C Web Content Accessibility Guidelines (WCAG) due to the quality of the documents and the process under which they were developed (See Note on other Accessibility Standards). At the time of publication, version 1.0 of WCAG is a W3C Recommendation [WCAG10], and a second version of the guidelines is under development [WCAG20]. Although a Web Content Accessibility "Benchmark" document may use either version of WCAG, developers should give consideration to the following when deciding which WCAG version to use in a product:

The latest version of WCAG will be the most accurate with respect to state-of-the-art technologies and accessibility best practices. Older versions of WCAG may include requirements that are no longer necessary, due to advances in user agent technology.
The versions of WCAG differ with respect to the formats for which there are published WCAG technique documents. This is important because the techniques documents may be useful when constructing Web Content Accessibility "Benchmark" documents as required by ATAG 2.0.
The versions of WCAG differ in the degree to which they match the legislation and policies that drive author requirements. Many authors will be seeking to use authoring tools to create Web content that meets legislation, corporate policies, etc. It is likely that as WCAG progresses, so too will legislation and policies, albeit at an uneven pace. Authoring tool developers may, therefore, consider supporting both versions of WCAG in the interim.

Editing View-Specific Techniques and Examples

Since the techniques and examples are intended to be as informative as possible, many of them are specific to certain types of editing views. Where this is the case they have been marked with icons as follows:

Instruction level editing views: Authors work with non-rendered instructions for the content being edited (e.g., HTML markup). Examples include plain text editing views as well as form-based editing views that provide direct access to the instructions (e.g., selecting attribute values).
Content rendering editing views: Authors work with content that is fully or partially rendered, played, or executed. Partial renderings occur when only some aspects of the content are rendered, played, or executed. For example, a frame-by-frame video editor may render the graphical aspects, but not the temporal aspect of a video. Some renderings are WYSIWYG because they closely resemble the appearance and behavior that a user agent would produce (e.g., an HTML editor that displays rich text, images, tables, etc.), while others are non-WYSIWYG because they differ from those produced by user agents (e.g., a graphical wavefront editing view of an audio file).
Meta-content editing views: Authors work with higher-level or abstract information that the authoring tool interprets to generate the resulting content. For example, a content management system that allows authors very limited control (e.g., toggling on/off, setting colors) over it's built-in content modules (e.g. stock ticker, calendar).

ATAG 2.0 Implementation Techniques

The guidelines and success criteria are included here for informative purposes. The normative version appears in the Authoring Tool Accessibility Guidelines 2.0 [ATAG20].

PART A: Make the authoring tool user interface accessible

Conformance Notes for Part A:

Rendering inaccessible content: In most cases authoring tools are responsible for providing accessible content displays, however accessibility problems in content renderings that are due to the existence of accessibility problems in the content being edited are exempt from the requirements (e.g., if content does not include a text label for an image, it is permissible for a WYSIWYG rendering of that image to lack a label).

PRINCIPLE A.1: Authoring tool must facilitate access by assistive technologies

Guideline A.1.1 [For the authoring tool user interface] Ensure that Web-based functionality is accessible. [Return to Guideline]

Rationale: In addition to generally improving the accessibility of the authoring tool user interface, implementing Web-based functionality (e.g., editing views, documentation) using accessible Web content facilitates communication with assistive technologies via user agents.

Applicability Reminder: Remember that this guideline is only applicable to Web-based authoring tool user interfaces. This includes full Web applications as well as parts of authoring tools that are Web-based (e.g., help systems) even when the rest of the authoring tool is non Web-based.

Level A Success Criteria for Guideline A.1.1

A.1.1.1 Web-Based "A" Accessible: Web-based authoring tool user interfaces meet the level "A" Web content accessibility benchmarks.
- Technique A.1.1.1-1 [Advisory]: Selecting a target Web content accessibility standard (e.g., WCAG 2.0 [WCAG20]) in the early stages of development planning.
- Technique A.1.1.1-2 [Sufficient]: Following the requirements of the target Web content accessibility standard when developing any Web-based functionality. This means implementing all of the requirements of the level "A" Web content accessibility benchmark (specified in the conformance claim) for the technologies in which the authoring tool is implemented.
- Technique A.1.1.1-3 [Advisory]: Testing Web-based authoring tool user interfaces using automated evaluation and repair tools.
  - Example: Throughout development of an authoring tool, with the tool in various representative states, the editing interface (including test content being authored) is tested using accessibility evaluation software. Problems are corrected and the process iterates.

Level AA Success Criteria for Guideline A.1.1

A.1.1.2 Web-Based "AA" Accessible: Web-based authoring tool user interfaces meet the level "AA" Web content accessibility benchmarks.
- See Techniques for A.1.1.1 using level "AA" Web content accessibility benchmarks.

Level AAA Success Criteria for Guideline A.1.1

A.1.1.3 Web-Based "AAA" Accessible: Web-based authoring tool user interfaces meet the level "AAA" Web content accessibility benchmarks.
- See Techniques for A.1.1.1 using level "AAA" Web content accessibility benchmarks.

Applicability Note: This guideline does not apply to non-Web-based authoring tool user interfaces.

Guideline A.1.2 [For the authoring tool user interface] Support interoperability with assistive technologies. [Return to Guideline]

Rationale: Assistive technologies that are used by many people with disabilities (e.g., screen readers, screen magnifiers, on-screen keyboards, voice recognition systems) rely on the authoring tool to provide data and control via prescribed communication protocols.

Applicability Reminder: Remember that this guideline is only applicable to non-Web-based authoring tool user interfaces, since it is assumed that user agents will mediate the communication for Web-based authoring tools. Note that some of the success criteria only apply when the accessibility platform architecture(s) have been implemented improperly.

Level A Success Criteria for Guideline A.1.2

A.1.2.1 Accessibility Platform Architecture (user interface "chrome", content display): Non-Web-based authoring user interfaces implement an accessibility platform architecture relevant to the platform.
- Technique A.1.2.1-1 [Sufficient]: Implementing the relevant accessibility platform architecture(s), such as:
  - Gnome Accessibility: Gnome Accessibility Toolkit API [GNOME-API]
  - Eclipse Accessibility: Eclipse Platform API [ECLIPSE-API]
  - Java Swing: Java Accessibility Package [JAVA-API]
  - MacOS X Accessibility:
    - "Introduction to Accessibility Programming Guidelines for Carbon" [CARBON-ACCESS]
    - "Introduction to Accessibility Programming Guidelines for Cocoa" [COCOA-ACCESS]
  - Microsoft Windows Active Accessibility: Microsoft Active Accessibility [MSAA-API]
A.1.2.2 Accessible Alternative (user interface "chrome", content display): If any non-Web-based authoring user interface functionality is not supported by the implemented accessibility platform architecture(s), then a separate accessible alternative for that functionality that is supported by the implemented accessibility platform architecture(s) is provided and a description of the inaccessible functionality appears in the conformance claim.
- Technique A.1.2.2-1 [Sufficient]: Providing equivalent functionality that is supported by the relevant accessibility platform architecture(s) and describing the inaccessible functionality in the conformance claim.
  - Example: A given tool includes a "node graph" view of sites to show where broken links occur. Because this custom view is not supported by the relevant accessibility platform architecture, the same information is also available in a list that is supported.

Level AA Success Criteria for Guideline A.1.2

A.1.2.3 Deviation from Proper Use (user interface "chrome", content display): If any non-Web-based authoring user interface functionality deviates from the proper use of the implemented accessibility platform architecture(s) (i.e., lack of use, incomplete use, inappropriate use) as defined by the documentation for the accessibility platform architecture(s), this is documented with the conformance claim.
- Technique A.1.2.3-1 [Sufficient]: Fully describing the deviation in the conformance claim in terms that would be useful to a third party developer of assistive technologies.

Level AAA Success Criteria for Guideline A.1.2

A.1.2.4 Additional Information (user interface "chrome", content display): For non-Web-based authoring user interfaces, additional information is published describing the nature of the implementation of the accessibility platform architecture(s) (e.g., that the long description is different from the associated tool tip).
- Technique A.1.2.4-1 [Sufficient]: Describing how the information provided for each focusable user interface component through the accessibility platform architecture might differ from the corresponding information provided directly by the component itself (e.g., if a button component provides different "accessible name" text than it uses as "displayed text" or if the button only displays an image) and why the difference exists.

Applicability Note: This guideline does not apply to Web-based authoring tool user interface functionality.

Guideline A.1.3 [For the authoring tool user interface] Follow the accessibility conventions of the platform. [Return to Guideline]

Rationale: Following platform accessibility conventions lessens the need for assistive technologies to make special-purpose accommodations. Also, people who are familiar with the accessibility conventions employed by a specific platform will find applications that adhere to those conventions easier to use.

Level A Success Criteria for Guideline A.1.3

A.1.3.1 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following:
- (a) Input: Keyboard, mouse, etc. including non-interference with keyboard accessibility features of the platform (e.g., StickyKeys, SlowKeys, browser link navigation)
- (b) Focus
- (c) Selection, and
- (d) Product installation.
- Technique A.1.3.1-1 [Sufficient]: Implementing the input, focus, selection and product installation sections of accessibility guidelines and best practice documents that are relevant to the platform. These may include:
  - Eclipse: "Designing Accessible Plug-ins in Eclipse" [ECLIPSE-ACCESS]
  - Gnome/KDE:
    - "GNOME Accessibility for Developers" [GNOME-ACCESS]
    - "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]
  - Java:
    - "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS]
    - "Java accessibility guidelines and checklist" [JAVA-CHECKLIST]
  - Lotus Notes: "Lotus Notes accessibility guidelines" [NOTES-ACCESS]
  - MacOS: "Accessibility Documentation" [APPLE-ACCESS]
  - Microsoft Windows:
    - "Accessibility for applications designers" [MS-ENABLE]
    - "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
  - General Guides:
    - "Application Software Design Guidelines" [TRACE-REF]
    - "Ergonomics of human-system interaction -- Guidance on accessibility for human-computer interfaces" ISO standard [ISO-TS-16071]
    - "Designing for Accessibility" [SUN-DESIGN]
    - "[Electronic Information Technology Access Advisory Committee] EITAAC Desktop Software standards" [EITAAC]
    - "Making Educational Software and Web Sites Accessible" [EDU-SOFT-ACCESS]
    - "Software Accessibility" [IBM-ACCESS]
    - "What is Accessible Software" [WHAT-IS]
  Technique A.1.3.1-2 [Advisory]: Including authors with disabilities and authors using assistive technologies in focus groups and user testing throughout the design and development of the authoring tool user interface. The following are resources related to inclusive user testing:
  - "Involving Users in Web Accessibility Evaluation" [USER-TEST-WEB]
  - "Just Ask: Integrating Accessibility Throughout Design" [USER-TEST-UCD]

Level AA Success Criteria for Guideline A.1.3

A.1.3.2 Follow and Cite Conventions (user interface "chrome", content display): Platform conventions are followed and the convention sources are cited for all of the following:
- (a) User interface design,
- (b) Keyboard configuration, and
- (c) Documentation.
- Technique A.1.3.2-1 [Sufficient]: Implementing the user interface design, keyboard configuration, and documentation sections of accessibility guidelines and best practice documents that are relevant to the platform. See Techniques in A.1.3.1 for links to resources.

Level AAA Success Criteria for Guideline A.1.3

(No level AAA success criteria for Guideline A.1.3)

PRINCIPLE A.2: Authoring tool user interface must be perceivable

Guideline A.2.1 [For the authoring tool user interface] Display text alternatives for non-text objects. [Return to Guideline]

Rationale: People who have difficulty perceiving non-text objects are often able to access text alternatives of the same information because there are a variety of ways to display text (e.g., magnification, enhancement, text-to-speech, Braille output)

Applicability Reminder: Note that the first success criteria only applies when non-text objects are rendered in an editing view. This exempts plain text editors.

Level A Success Criteria for Guideline A.2.1

A.2.1.1 Editing Non-text Objects (content display): Editing views that render non-text objects contained within the content being edited can display any text alternatives that are identifiable by the authoring tool. It is permissible for the authoring tool to change editing views to display the text alternatives (e.g., from WYSIWYG to instruction level).
- Technique A.2.1.1-1 [Sufficient]: In editing views that render non-text objects, displaying in an editable fashion any text alternatives (e.g., short text labels, long text descriptions) associated with the objects (e.g., within a properties dialog).
- Technique A.2.1.1-2 [Sufficient]: When appropriate for a Web technology (i.e., the technology is human-readable), providing an instruction level editing view that allows direct editing of all properties.
- Technique A.2.1.1-3 [Advisory]: Providing an option to toggle between rendered non-text objects and the text alternatives for the objects.
  - Example: An option to toggle fully rendered images with their text alternatives. On the left is the image (of the "earthrise" as seen from the moon) rendered as usual. On the right is a different rendering, this one including an area for editing the alternate text and a link to edit the long description. A small preview rendering of the image is included to provide context. (Source: mockup by AUWG)
A.2.1.2 Non-text Objects (user interface "chrome"): Non-text objects in the "chrome" have text alternatives that present equivalent information, except for the situations listed below. [WCAG 2.0]
- (a) Controls-Input: If a non-text object is a control or accepts user input, then it has a name that describes its purpose. [WCAG 2.0]
- (b) Sensory: If a non-text object is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text object. [WCAG 2.0]
- (c) Decoration, Formatting, Invisible: If a non-text object provides no information or functionality, or is used only for visual formatting or is not presented to users, then it is implemented such that it can be ignored by assistive technology. [WCAG 2.0]
- Technique A.2.1.2-1 [Sufficient in combination]: If a short description can serve the same purpose and present the same information as the non-text content, providing the short text description.
  - Example: The Web-based documentation for an authoring tool includes the developer's logotype. The logotype includes the company name as alternative text.
- Technique A.2.1.2-2 [Sufficient in combination]: If a short description can not serve the same purpose and present the same information as the non-text content, providing a short text and a longer text description in the nearby text or via a link.
  - Example: The documentation of an authoring tool includes a screenshot that shows how to start a new document. The same information is provided in step-by-step text near the screenshot and image labels informs the author of this.
- Technique A.2.1.2-3 [Sufficient in combination]: If non-text content is a control or accepts user input, including a text alternative identifies the purpose of the content.
  - Example: An authoring tool has an toolbar of buttons labeled with icons. Each button is also labeled programmatically with the function of the button, rather than a description of its icon.
- Technique A.2.1.2-4 [Sufficient in combination]: If a non-text object is primarily intended to create a specific sensory experience (e.g., in a tutorial example) , providing text alternatives for descriptive identification of the non-text object.
  - Example: An authoring tool includes a highly visual splash screen that welcomes the author. The screen is labeled with a welcome message.
- Technique A.2.1.2-5 [Sufficient in combination]: If a non-text object provides no information or functionality, or is used only for visual formatting or is not presented to users, ensuring that it can be ignored by assistive technology.
  - Example: The Web-based documentation for an authoring tool includes spacer images. These are labeled with null labels to inform assistive technologies that they can be ignored.
- Technique A.2.1.2-6 [Advisory]: For tools that display the source structure of markup documents using graphic representations of tags, providing the author with the option of displaying the tag information as text.
  - Example: An authoring tool has a view that is WYSIWYG except that graphics are added to the editing view to show where elements start and end. In the author preferences of the tool, there is an option to "Show tags as text", which replaces the tag graphics with the actual text of the tags.
  Technique A.2.1.2-7 [Advisory]: For tools that display collections of content using graphic representations of the objects, links, etc., providing the author with the option of displaying the information as text. (e.g., as a tree view).

Level AA Success Criteria for Guideline A.2.1

(No level AA success criteria for Guideline A.2.1)

Level AAA Success Criteria for Guideline A.2.1

(No level AAA success criteria for Guideline A.2.1)

Guideline A.2.2 [For the authoring tool user interface] Display synchronized alternatives for synchronized media. [Return to Guideline]

Rationale: People who have difficulty accessing or interpreting synchronized media can have the information made available to them by other means. For example, people who are deaf or have a hearing loss can access auditory information through captions. People who are blind or have low vision, as well as those with cognitive disabilities, who have difficulty interpreting visually what is happening, can receive audio descriptions of visual information.

Applicability Reminder: Note that many of the success criteria in this guideline only apply when there is prerecorded synchronized media (e.g., audio, video) in the "chrome" (as opposed to any rendered editing views), which is currently not very common for authoring tools.

Level A Success Criteria for Guideline A.2.2

A.2.2.1 Accessible Synchronized Media During Editing (content display): Editing views that render synchronized media contained within the content being edited can display any synchronized alternatives that are identifiable by the authoring tool (e.g., WYSIWYG editing views).
- Technique A.2.2.1-1 [Sufficient]: In editing views that render multimedia, also displaying any associated synchronized alternatives (e.g., captions for video, captions for audio files, audio descriptions for videos).
A.2.2.2 Captions (user interface "chrome"): If prerecorded audio is present in the user interface "chrome", then captions are provided. [WCAG 2.0]
- Technique A.2.2.2-1 [Sufficient]: Providing open captions (i.e., always visible).
- Technique A.2.2.2-2 [Sufficient]: Providing closed captions (i.e., captions shown by user request).
A.2.2.3 Visual Information (user interface "chrome"): If prerecorded video is present in the user interface "chrome", then at least one of the following are true: [WCAG 2.0]
- (a) Audio Track: all of the information in the video track is provided in the audio track,
- (b) Audio Descriptions: audio descriptions are provided, or
- (c) Full Text Alternatives: full text alternative for synchronized media including any interaction are provided.
- Technique A.2.2.3-1 [Sufficient]: Providing an audio track that describes the same information that the visual track is intended to convey.
- Technique A.2.2.3-2 [Sufficient]: Providing an audio description option.
  - Example: Two versions of the tutorial videos are offered. A version with and a version without audio descriptions. The two versions are implemented using SMIL to combine a video track with a basic audio track and then a second descriptions audio track if that option is selected.
- Technique A.2.2.3-3 [Sufficient]: Providing a full text alternative that provides the same information and functionality as the video.

Level AA Success Criteria for Guideline A.2.2

A.2.2.4 Audio Description (user interface "chrome"): If prerecorded video is present in the user interface "chrome", then at least one of the following are true: [WCAG 2.0]
- (a) Audio Track: all of the information in the video track is provided in the audio track, or
- (b) Audio Descriptions: audio descriptions are provided.
- See Techniques A.2.2.3-1 and A.2.2.3-2.

Level AAA Success Criteria for Guideline A.2.2

A.2.2.5 Sign Language (user interface "chrome"): If prerecorded audio is present in the user interface "chrome", then sign language interpretation is provided. [WCAG 2.0]
- Technique A.2.2.5-1 [Sufficient]: Including a sign language interpreter in the video.
- Technique A.2.2.5-2 [Sufficient]: Providing a new page that has the video with the sign language interpretation of the audio track.
A.2.2.6 Audio Description (Extended): If prerecorded video is present in the user interface "chrome", then extended audio description is provided. [WCAG 2.0]
- Technique A.2.2.6-1 [Sufficient] Providing a second version of the video with extended audio descriptions during halted video segments, as necessary to convey any visual information.
A.2.2.7 Full Text Alternative (user interface "chrome"): If prerecorded synchronized media is present in the user interface "chrome", then full text alternative for synchronized media including any interaction is provided. [WCAG 2.0]
- See Technique A.2.2.3-3.

Guideline A.2.3 [For the authoring tool user interface] Ensure that the interface can be presented in different ways. [Return to Guideline]

Rationale: Authors need to have access to both the functional significance of presentation and also, in the context of authoring, to the presentation that will be experienced by the end user.

Level A Success Criteria for Guideline A.2.3

A.2.3.1 Name, Role, Value (user interface "chrome"): For all user interface components in the user interface "chrome", all of the following are true: [WCAG 2.0]
- (a) the name and role are available via the platform,
- (b) states, properties, and values that can be set by authors are available via the platform, and
- (c) notification of changes to these items is available via the platform.
- Technique A.2.3.1-1 [Sufficient]: The user interface "chrome" is implemented (properly) using a standard toolkit that is known to implement communication via the platform (e.g., standard HTML elements, Java Swing, MFC, etc.).
- Technique A.2.3.1-2 [Sufficient in combination]: Making the name and role for all user interface components in the "chrome" available via the platform.
  - Example: A Web-based authoring tool includes a progress bar, implemented in JavaScript, that displays the time remaining in a conversion process. Using ARIA, the component is given the name "ConversionStatus" and the role "progressbar".
- Technique A.2.3.1-3 [Sufficient in combination]: Making the states, properties, and values that can be set by authors available via the platform.
- Technique A.2.3.1-4 [Sufficient in combination]: Making the notification of changes to these items available via the platform.
A.2.3.2 Info and Relationships (user interface "chrome"): In the user interface "chrome", information, structure, and relationships conveyed through presentation is available via the platform or are available in text. [WCAG 2.0]
- Technique A.2.3.2-1 [Sufficient]: Ensuring that information, structure, and relationships conveyed through presentation is available via the platform.
  - Example: A caption editing tool includes a spreadsheet view with the following headers: "time in", "time-out", "primary caption", "secondary caption". The spreadsheet is implemented such that each cell has its respective header programmatically identified as a "label" (e.g., "labeledby").
- Technique A.2.3.2-2 [Sufficient]: Ensuring that information, structure, and relationships conveyed through presentation is available in text.
  - Example: A broken link checking system includes two views: a graphical view in which the pages on a site are shown as nodes and the links leading from them as lines that either connect to another node or are highlighted in red, and a second textual view that simply lists the broken links.
A.2.3.3 Purpose of Added Presentation (content display): If the authoring tool modifies the presentation of the content being edited, then the functional purpose for the modification is made available via the platform (e.g., if misspelled text is underlined, the fact that it is is misspelled is important).
- Technique A.2.3.3-1 [Sufficient]: Making available via the platform semantics for any presentation that is added to the editing view by the authoring tool.
  - Example: A change tracking feature displays inserted text in green and deleted text in red with a strikethrough. Instead of implementing this using simple CSS selectors, the XHTML elements ins and del are used, since they have associated semantics.
A.2.3.4 Access to Presentation Being Edited (content displays): If an editing view (e.g., WYSIWYG) renders any of the following text presentation properties and those properties are editable by any editing view (e.g., instruction level), then the properties are made available via the platform:
- (a) font,
- (b) style (e.g., italic, bold),
- (c) color, and
- (d) size.
- Technique A.2.3.4-1 [Sufficient]: Making available via the platform, information on the size, font, foreground and background color, font weight, and position of any text that is under the control of the author.
  - Example: Using a WYSIWYG authoring tool, an author is able to mark a paragraph using a "footnote" style class, then query the text to check on the rendered size of the text to ensure that the styling information has been picked up properly.
A.2.3.5 Meaningful Sequence (user interface "chrome"): When the sequence in which user interface "chrome" components are presented affect their meaning, a correct reading sequence is available via the platform. [WCAG 2.0]
- Technique A.2.3.5-1 [Sufficient]: Ensuring a correct reading sequence is provided for user interface "chrome" components that may change in meaning according to their sequence.
  - Example: Using tab ordering to provide the correct sequence of controls.
A.2.3.6 Sensory Characteristics (user interface "chrome"): Instructions provided for understanding and operating the user interface "chrome" do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound. [WCAG 2.0]
- Technique A.2.3.6-1 [Sufficient]: Providing instructions for understanding and operating the user interface "chrome" that do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound
  - Example: A round button is provided on a Wiki to submit changes. The button is labeled with the text "Save." The instructions state, "to save the changes press the round button labeled Save". This includes both shape and textual information to locate the button.

Level AA Success Criteria for Guideline A.2.3

(No level AA success criteria for Guideline A.2.3)

Level AAA Success Criteria for Guideline A.2.3

A.2.3.7 Access to Presentation Being Edited (content displays): Any text presentation properties (text size, positioning, etc.) that are rendered in an editing view (e.g., WYSIWYG editing views ) and editable by any editing view are available via the platform.
- See Techniques for A.2.3.4, but for all text presentation properties rendered and editable by the authoring tool.

Guideline A.2.4 [For the authoring tool user interface] Make it easier to see and hear the interface. [Return to Guideline]

Rationale: Some authors require display settings that differ from the presentation that they intend to define for the published content (e.g., using a high contrast setting during editing content that is not intended to be high contrast).

Level A Success Criteria for Guideline A.2.4

A.2.4.1 Independence of Display (content display): Editing views that usually have their display characteristics set by rendering the content being edited (e.g., WYSIWYG editing views)allows the authors' visual and audio display settings to override these characteristics without affecting the content (e.g., markup, stylesheets, etc.) being edited.
- Technique A.2.4.1-1 [Sufficient]: Providing the author with the ability to change the fonts, colors, sizing (zoom), etc. within rendered editing views (or by changing the platform display settings), independently of the ability to control the markup that is actually produced.
  - Example: A WYSIWYG authoring tool includes editing interface controls for setting the text and background colors as they will appear to the end user, but also includes a "View" area in its preference settings, where the author can choose to override the WYSIWYG rendering with their own text and background color settings.
- Technique A.2.4.1-2 [Advisory]: Allowing the author to specify a preferred style sheet that is used in the editing view to override the actual "published" style of the document.
A.2.4.2 Use of Color (user interface "chrome", content display): Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. [WCAG 2.0]
- Technique A.2.4.2-1 [Sufficient]: Ensuring (by design, testing on monochrome displays, including color blind individuals in testing, etc.), that color alone is not required to identify any single element of the editing interface of the tool.
  - Example: A multimedia authoring tool has toolbar buttons controls to stop and start the playing of the timed content. Instead of using a red circle for "stop" and a green circle for "go", the tool observes the "video" control conventions and uses redundant shape information: a red square for "stop" and a green triangle for "go".
- Technique A.2.4.2-2 [Sufficient ]: Providing an alternative route to the same information or functionality that is accessed via an element of the editing interface of the tool that requires color discrimination to understand or access.
  - Example: An authoring tool has a multimedia tutorial that plays lessons. At various places the author is able to click the presentation to make decisions about what to see next. The tool makes this feature accessible by providing an HTML-based accessible version that contains all of the same information.
A.2.4.3 Audio Control (user interface "chrome", content display): If any audio plays automatically for more than 3 seconds, at least one of the following is true:
- (a) Pause: authors can pause or stop the audio, or
- (b) Control: authors can set the audio volume to a different level from the system volume level. [WCAG 2.0]
- Technique A.2.4.3-1 [Sufficient]: Ensuring automatically playing audio only does so for less than 3 seconds..
- Technique A.2.4.3-2 [Sufficient]: Providing a user interface control to pause or stop automatically playing audio (e.g., by pausing a video that starts automatically in the tutorials).
- Technique A.2.4.3-3 [Sufficient]: Providing the ability for the author to set volume for automatically playing audio, which is independent of the system volume level.
A.2.4.4 Visual Display (user interface "chrome", content display): If a visual display is provided, authors can configure the visual display settings (i.e., fonts, sizes, colors, spacing, positioning, and contrast) by at least one of the following methods:
- (a) Platform Settings: an option to inherit the platform settings, or
- (b) Tool Specific Settings: content display settings specific to the authoring tool.
- Technique A.2.4.4-1 [Sufficient]: Inheriting the platform visual display settings.
- Technique A.2.4.4-2 [Sufficient]: Providing tool specific settings for the visual display.
A.2.4.5 Audio Display (user interface "chrome", content display): If an audio display is provided, authors can configure the audio display settings (i.e., volume, speech voices, voice speed, and voice emphasis) by at least one of the following methods:
- (a) Platform Settings: an option to inherit the platform settings, or
- (b) Tool Specific Settings: content display settings specific to the authoring tool.
- Technique A.2.4.5-1 [Sufficient]: Inheriting the platform audio display settings.
- Technique A.2.4.5-2 [Sufficient]: Providing tool specific settings for the audio display.

Level AA Success Criteria for Guideline A.2.4

A.2.4.6 Visual Configurability (user interface "chrome", content display): If the visual display settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least comparable configuration ranges as the platform provides.
- Technique A.2.4.6-1 [Sufficient]: Providing options to modify the same visual display parameters within the same range as the platform specified in the conformance profile (e.g., in terms of font settings for an authoring tool running on Windows XP, this means supporting: a wide range of serif and non-serif fonts; text sizes between 6pt and 24pt; at least 256 color choices for text and backgrounds; font face settings of regular, bold or italic; but no specific settings for text spacing or positioning)
A.2.4.7 Audio Configurability (user interface "chrome", content display): If the audio display settings are not inherited from the platform settings, then the authoring tool provides at least comparable configurable properties with at least comparable configuration ranges as the platform provides.
- Technique A.2.4.7-1 [Sufficient]: Providing options to modify the same audio display parameters within the same range as the platform (e.g., for an authoring tool running on Windows XP this means supporting: volumes between "mute" and the maximum allowed by the current setting of the physical speakers; the ability to substitute different sound files for any "alert" sound effect; at least three voice choices and a very wide reading speed range, if voice output is a feature)

Level AAA Success Criteria for Guideline A.2.4

A.2.4.8 Low or No Background Audio (user interface "chrome"): Audio that contains speech in the foreground does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground speech, with the exception of occasional sound effects. Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech. [WCAG 2.0]
- Technique A.2.4.8-1 [Sufficient]: Ensuring audio with speech in the foreground does not include background sounds.
- Technique A.2.4.8-2 [Sufficient]: Ensuring audio with speech in the foreground only includes background sounds at least 20 decibels lower than the speech.

Note: While the success criteria for this guideline are based on the capabilities of the platforms (e.g., operating systems, user agents, GUI toolkits) listed in the conformance profile, additional configuration settings may be provided.

PRINCIPLE A.3: Authoring tool user interface must be operable

Guideline A.3.1 [For the authoring tool user interface] Ensure that all functionality is available from a keyboard. [Return to Guideline]

Rationale: Providing alternate keyboard accessibility provides access for people with limited mobility and people with visual disabilities, who cannot rely on hand-eye coordination for navigating the user interface.

Level A Success Criteria for Guideline A.3.1

A.3.1.1 Keyboard (user interface "chrome", content display): Authors can, through keyboard input alone, navigate to and operate all of the functions included in the authoring tool user interface (e.g., navigating, selecting, and editing content within editing views, operating the user interface "chrome", installing and configuring the tool, and accessing documentation), except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., freeform drawing). This applies to at least one mechanism per authoring outcome. This means non-keyboard accessible mechanisms can remain available (e.g., providing resizing with mouse-"handles" and with a properties dialog). [WCAG 2.0, UAAG 2.0]
- Technique A.3.1.1-1 [Sufficient in combination]: Providing sequential keyboard access (with different keystrokes) for moving the focus between user interface areas (e.g., from the menus to the editing view to the floating toolbars, etc.) and editing views.
- Technique A.3.1.1-2 [Sufficient in combination]: Providing sequential keyboard access (with different keystrokes) for moving the focus within all of the controls within each user interface area (e.g., the menu items, the editing view objects, the floating toolbar controls) and editing view.
- Technique A.3.1.1-3 [Sufficient in combination]: Providing the ability to operate any control with the keyboard alone.
- Technique A.3.1.1-4 [Advisory]: Providing direct keyboard access (such as via keyboard accelerators) to frequently used functions or to functions that may be located further along in the sequential tab order than its frequency of use would warrant.
- Technique A.3.1.1-5 [Advisory]: Providing mouse only controls only when equivalent keyboard accessible functionality is also provided.
  - Example: An authoring user interface has both mouse-driven and keyboard-driven mechanisms for editing the height and width properties of an image. On the left is the keyboard-driven version, which takes the form of height and width attribute fields in the image properties dialog box. On the right is the mouse-driven mechanism, which takes the form of graphical handles surrounding a rendering of the image (of the "earthrise" as seen from the moon). These let the author manipulate the image size directly. (Source: mockup by AUWG)
- Technique A.3.1.1-6 [Advisory]: Providing a mode in which any accesskeys defined in the content can be used by the author to navigate the editing view of the content.
A.3.1.2 No Keyboard Trap (user interface "chrome", content display): If focus can be moved to a component with the keyboard, then at least one of the following is true:
- (a) standard keys: focus can be moved away from the component with the keyboard using standard navigation keys (i.e., unmodified arrow or tab keys), or
- (b) documented non-standard keys: focus can be moved away from the component with non-standard keys and the author is advised of the method. [WCAG 2.0]
- Technique A.3.1.2-1 [Sufficient]: Allowing standard keyboard controls (i.e., arrow keys and tab) to move the focus away from any focusable component in the "chrome" or content display.
- Technique A.3.1.2-2 [Sufficient]: Ensuring that if the standard keyboard controls are unavailable (e.g., due to a compound document conflict), the necessary keyboard controls are documented in text close to the component and via the platform.
A.3.1.3 Available Keystrokes (user interface "chrome", content display): Authors can always determine the currently available keystrokes (e.g., from a central location such as a list in the help system or a distributed location such as associating shortcuts with menu items). [UAAG 2.0]
- Technique A.3.1.3-1 [Sufficient]: Providing a documentation page that lists all of the keystrokes.
- Technique A.3.1.3-2 [Sufficient]: Providing the keystrokes throughout the authoring tool user interface according to the platform conventions (e.g. listing associated shortcut keys with menu items).
A.3.1.4 Standard Text Area Conventions (content display): Editing views that allow text entry support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, "arrow" key navigation, page up/page down, navigate to start/end, navigate by paragraph, shift-to-select mechanism, etc.
- Technique A.3.1.4-1 [Sufficient]: Using standard text entry components for the platform.
A.3.1.5 "Chrome" Navigation (user interface "chrome"): Authors can use the keyboard to traverse forwards/backwards all of the components, including those in floating toolbars, panels, etc. using conventions of the platform (e.g., via "tab", "shift-tab", "ctrl-tab", "ctrl-shift-tab"). [UAAG 2.0]
- Technique A.3.1.5-1 [Sufficient]: Ensure that the author can navigate to all components, even those in floating toolbars, etc..

Level AA Success Criteria for Guideline A.3.1

A.3.1.6 Accelerator Keys (user interface "chrome"): If the authoring tool includes any of the following functions, authors can enable key-plus-modifier-key (or single-key) access to them:
- (a) open help system,
- (b) open new content,
- (c) open existing content,
- (d) save content,
- (e) close content,
- (f) cut/copy/paste,
- (g) undo/redo, and
- (h) open find/replace function.
- Technique A.3.1.6-1 [Sufficient]: Providing key-plus-modifier-key (or single-key) access for all of the functions listed here.
  - Example: On a Windows platform, an authoring tool uses the following keyboard commands: opening help system (e.g., F1); open new content (e.g., ctrl-N); open existing content (e.g., ctrl-O); save content (e.g., ctrl-S); close content (e.g., ctrl-W); cut/copy/paste (e.g., ctrl-X, ctrl-C, ctrl-V); undo/redo (e.g., ctrl-Z, ctrl-Y); open find/replace function (e.g., ctrl-F, ctrl-H).
- Technique A.3.1.6-2 [Advisory]: Following platform conventions when choosing keystrokes, such as:
  - MacOS: "Mac OS X keyboard shortcuts" [MACOSX-KEYS]
  - Windows: "Keyboard shortcuts for Windows" [MS-KEYS]
  - Gnome/KDE: "Gnome/KDE Keyboard Shortcuts" [GNOME-KDE-KEYS]
- Technique A.3.1.6-3 [Advisory]: Expanding direct keyboard access beyond the functions listed in this success criterion to other frequently used functions of a tool (e.g., to perform text formatting, move quickly between windows, etc.).
A.3.1.7 Change Accelerator Keys (user interface "chrome"): Authors can modify key-plus-modifier-key (or single-key) combinations.
- Technique A.3.1.7-1 [Sufficient]: Providing a utility where the available functions can be mapped and re-mapped to the available keyboard combinations.

Level AAA Success Criteria for Guideline A.3.1

A.3.1.8 Inter-group Navigation (user interface "chrome", content display): If logical groups of focusable components (e.g., toolbars, dialogs, labeled groups, panels) are present, authors can use the keyboard to navigate to a focusable component in the next and previous groups. [UAAG 2.0]
- Technique A.3.1.8-1 [Sufficient]: Providing a key combination for navigating between the first items in logical groups of focusable components (e.g., ctrl-Tab).
A.3.1.9 Group Navigation (user interface "chrome", content display): If logical groups of focusable components are present, authors can use the keyboard to navigate to the first, last, next and previous focusable component within the current group. [UAAG 2.0]
- Technique A.3.1.9-1 [Sufficient]: Providing key combinations for navigating to the first, last, next and previous components from within a group.

Note 1: Web-based authoring tool user interface functionality may rely on the keyboard navigation functions of the user agent listed in the conformance profile to satisfy some of these success criteria.

Note 2: This guideline should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation. Also see Guideline A.3.1 when choosing keystrokes.

Guideline A.3.2 [For the authoring tool user interface] Enable time-independent interaction. [Return to Guideline]

Rationale: People who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits.

Applicability Reminder: Note that several of the success criteria in this guideline only apply when there are time limits put on the author, which is currently not very common for authoring tools.

Level A Success Criteria for Guideline A.3.2

A.3.2.1 Data Saved (user interface "chrome", content display): If the authoring tool ends an authoring session due to a time limit (e.g., authenticated session expires), then the content being edited is saved. For Web-Based Authoring Tools, this applies to any content that has already been submitted to the application by the user agent.
- Technique A.3.2.1-1 [Sufficient]: Whenever an authoring tool initiates the end of a session; it automatically saves all user data.
  - Example: A courseware tool will time-out a user after 10 minutes of inactivity. When this happens all of the submitted data is saved and a timeout function automatically submits the unsubmitted data as "draft data" that is then presented to the author at the start of the next session.
- Technique A.3.2.1-2 [Sufficient]: Whenever an authoring tool initiates the end of a session; it automatically saves all submitted user data.
A.3.2.2 Timing Adjustable (user interface "chrome", content display): If the authoring tool is responsible for imposing a time limit on authoring sessions (e.g., to mediate collaborative authoring), then authors can extend the time limit.
- Technique A.3.2.2-1 [Sufficient]: Providing a preference setting to universally extend all authoring tool-controlled time limits.
- Technique A.3.2.2-2 [Sufficient]: Allowing the author to extend authoring-controlled time limits whenever they occur.
A.3.2.3 Moving Targets (user interface "chrome"): If components that act as targets for authors' actions (e.g., are clickable, accept drag-and-drop actions) are capable of movement, then authors can stop that movement.
- Technique A.3.2.3-1 [Sufficient]: All components that can be targets for author actions can be stopped.
  - Example: In a timeline-based animation editor, a draggable time indicator moves when the animation is being previewed. This movement can be stopped with the "Stop" button.

Level AA Success Criteria for Guideline A.3.2

(No level AA success criteria for Guideline A.3.2)

Level AAA Success Criteria for Guideline A.3.2

A.3.2.4 No Time Limits: The authoring tool does not impose time limits on authoring sessions.
- Technique A.3.2.4-1 [Sufficient]: Ensuring that the authoring tool never imposes time limits
- Technique A.3.2.4-2 [Advisory]: Even if an external process is causing a time limit, considering ways to reduce the impact on the author (e.g., giving advance warning, assisting with the time-limited action, etc.).

Guideline A.3.3 [For the authoring tool user interface] Help authors avoid flashing that could cause seizures.[Return to Guideline]

Rationale: Flashing can cause seizures in people with photosensitive epilepsy.

Level A Success Criteria for Guideline A.3.3

A.3.3.1 Below Threshold (user interface "chrome"): The user interface "chrome" never violates the general flash or red flash thresholds.
- Technique A.3.3.1-1 [Sufficient]: The user interface "chrome" never flashes.
- Technique A.3.3.1-2 [Sufficient]: Providing an option for setting all flashing below the general flash or red flash thresholds.
A.3.3.2 Blinking Request (content display): If an editing view is capable of rendering content that explicitly requests to blink or flash (e.g. blink element), the rendering does not violate the general flash or red flash thresholds.
- Technique A.3.3.2-1 [Sufficient]: Providing an option that content that is recognized by the authoring tool as blinking or flashing will be rendered such that it does not violate the general flash or red flash thresholds.
  - Example: If the user requests blinking be slowed or stopped, recognized elements such as blink are rendered statically but unrecognized flashing such as a user added video with alternating black and white frames may continue to flash.
- Technique A.3.3.2-2 [Advisory]: Providing an option to completely freeze all rendering.

Level AA Success Criteria for Guideline A.3.3

(No level AA success criteria for Guideline A.3.3)

Level AAA Success Criteria for Guideline A.3.3

A.3.3.3 Three Flashes (user interface "chrome"): No part of the user interface "chrome" ever flashes more than three times in any one second period. [WCAG 2.0]
- See Techniques A.3.3.1-1.
- Technique A.3.3.3-1 [Sufficient]: Providing an option for disabling all flashing.

Guideline A.3.4 [For the authoring tool user interface] Provide navigation and editing via content structure. [Return to Guideline]

Rationale: People who have difficulty typing or operating the mouse benefit when the structure that may be inherent in certain content can be used to navigate more efficiently within editing views and to perform edits.

Level A Success Criteria for Guideline A.3.4

A.3.4.1 Edit by Structure (content display): If an editing view displays a structured element set, then authors can, with a simple action, select any element in the set and perform editing functions (e.g., cut, copy, paste, presentation) on that element, its contents, and its sub-elements.
- Technique A.3.4.1 [Sufficient]: Ensuring