AUTHORING TOOLS / A PUBLISHED WEB STANDARD

Explore
ATAG 2.0

Better tools. More accessible content. Learn how content management systems, editors and publishing platforms can work for authors with disabilities and help every author create accessible content.

TWO CONNECTED RESPONSIBILITIES

From the author to the audience

Part A · Use the toolAuthors can create and edit.

Part B · Shape the outputThe tool supports accessible content.

W3C Recommendation
24 September 2015
Source checked 15 September 2026

Read the dated standard →

One standard. Two sides of authoring.

PART A / 31 SUCCESS CRITERIA

Can the author use the interface?

Review editing views, toolbars, dialogs, preferences, previews and help. Keyboard operation, perceivable information, recovery and documentation make content creation possible for more people.

Explore the author’s experience →

PART B / 32 SUCCESS CRITERIA

Does the tool support accessible output?

Review generated markup, templates, alternative content, checking, repairs and teaching. Accessible authoring should be supported throughout the workflow, across relevant author roles.

Explore content production →

ATAG applies to more than traditional website editors: consider learning platforms, no-code builders, media tools, document-to-web converters and services that let people post content. This companion covers 2 parts, 8 principles, 24 guidelines and all 63 success criteria. It is an independent learning application; completing an activity is not a conformance result.

FIND / UNDERSTAND / APPLY

The ATAG 2.0 reference

Read an original plain-language explanation, try a practical review, then expand the exact W3C success criterion with its notes and conditions. The linked definitions and Part A/B applicability notes are part of understanding what applies.

Browse the eight principles

The 13 WCAG-dependent criteria appear in every level filter because their requirements scale with the WCAG level. “AAA provisions only” includes those 13 and the 11 fixed AAA criteria; it is not a complete AAA review. Use All levels for that.

63 success criteria across 24 guidelines.

PART A

Make the authoring tool user interface accessible

Part A conformance applicability notes W3C normative excerpt
  1. Scope of "authoring tool user interface": The Part A success criteria apply to all aspects of the authoring tool user interface that are concerned with producing the "included" web content technologies. This includes views of the web content being edited and features that are independent of the content being edited (e.g. menus, button bars, status bars, user preferences, documentation).
  2. Reflected content accessibility problems: The authoring tool is responsible for ensuring that editing-views display the web content being edited in a way that is more accessible to authors with disabilities (e.g. ensuring that text alternatives in the content can be programmatically determined). However, where an authoring tool user interface accessibility problem is caused directly by the content being edited (e.g. if an image in the content lacks a text alternative), then this would not be considered a deficiency in the accessibility of the authoring tool user interface.
  3. Developer control: The Part A success criteria only apply to the authoring tool user interface as it is provided by the developer. They do not apply to any subsequent modifications by parties other than the authoring tool developer (e.g. user modifications of default settings, third-party plug-ins).
  4. User agent features: Web-based authoring tools may rely on user agent features (e.g. keyboard navigation, find functions, display preferences, undo features) to satisfy success criteria. Conformance claims are optional, but any claim that is made must record the user agent(s).
  5. Accessibility of features provided to meet Part A: The Part A success criteria apply to the entire authoring tool user interface, including any features added to meet the success criteria in Part A (e.g. documentation, search functions). The only exemption is for preview features, as long as they meet the relevant success criteria in Guideline A.3.7. Previews are treated differently than editing-views because all authors, including those with disabilities, benefit when preview features accurately reflect the functionality of user agents that are actually in use by end users.
  6. Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria only apply when these semantics are encoded programmatically (e.g. text describing an image can only be considered a text alternatives for non-text content when this role is encoded within markup).

Read these notes in the Recommendation

A.1 Authoring tool user interfaces follow applicable accessibility guidelines

GUIDELINE A.1.1

Ensure that web-based functionality is accessible

Make the editing interface usable on the web.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Review a complete CMS task with keyboard, browser zoom and a screen reader: sign in, create a draft, open formatting controls, upload an image, resolve a validation message and publish. Include dialogs, authentication and the media library in your scope.

A concrete example

A content editor can enter the image dialog, identify the alternative-text field, save and return to the selected image. A publicly accessible article does not compensate for an inaccessible editing dialog.

W3C guideline and rationale · Implementation guidance

A.1.1.1 A / AA / AAA · WCAG-dependentWeb-Based Accessible (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool contains web-based user interfaces, then those web-based user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

GUIDELINE A.1.2

Ensure that non-web-based functionality is accessible

Connect desktop authoring interfaces to their platform.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

For a desktop editor, identify the platform accessibility guidelines and services it implements. Inspect names, roles, values and focus in its accessibility tree, then perform real editing tasks with the platform’s assistive technology.

A concrete example

A desktop page builder exposes its object list and selected object through the operating system’s accessibility API. The same review includes custom property panels rather than stopping at standard menus.

W3C guideline and rationale · Implementation guidance

A.1.2.1 Level AAccessibility Guidelines

W3C Recommendation excerpt · 24 September 2015

If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces follow user interface accessibility guidelines for the platform. (Level A)

A.1.2.2 Level APlatform Accessibility Services

W3C Recommendation excerpt · 24 September 2015

If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services. (Level A)

A.2 Editing-views are perceivable

GUIDELINE A.2.1

Make alternative content available to authors

Let authors perceive the alternatives already in their content.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Open a draft containing meaningful images and a captioned video. Check whether their associated alternatives can be reached while editing, and whether time-based alternatives can be rendered or previewed in a suitable user agent.

A concrete example

An author who cannot see an image can read its existing alternative text in the editor. When reviewing a video, the author can inspect its captions rather than receiving only a silent thumbnail.

W3C guideline and rationale · Implementation guidance

A.2.1.1 Level AText Alternatives for Rendered Non-Text Content
A.2.1.2 Level AAlternatives for Rendered Time-Based Media

W3C Recommendation excerpt · 24 September 2015

If an editing-view renders time-based media, then at least one of the following is true: (Level A)

  • (a) Option to Render: The authoring tool provides the option to render alternatives for the time-based media; or
  • (b) User Agent Option: Authors have the option to preview the time-based media in a user agent that is able to render the alternatives.

GUIDELINE A.2.2

Ensure that editing-view presentation can be programmatically determined

Expose meaning that the editor communicates visually.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Inspect the editor’s spelling indicators, tracked changes and editable text properties. Check the programmatic information as well as the visual presentation; note which property or status cannot be determined.

A concrete example

A red underline is accompanied by an accessible indication of a spelling issue, and an author can determine the formatting applied to selected text without relying on the toolbar’s color.

W3C guideline and rationale · Implementation guidance

A.2.2.1 Level AEditing-View Status Indicators

W3C Recommendation excerpt · 24 September 2015

If an editing-view adds status indicators to the content being edited, then the information being conveyed by the status indicators can be programmatically determined. (Level A)

  • Note: Status indicators may indicate errors (e.g. spelling errors), tracked changes, hidden elements, or other information.
A.2.2.2 Level AAAccess to Rendered Text Properties

W3C Recommendation excerpt · 24 September 2015

If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined. (Level AA)

A.3 Editing-views are operable

GUIDELINE A.3.1

Provide keyboard access to authoring features

Make authoring tasks possible and efficient with a keyboard.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Create and reorder content, select an image, use the toolbar and leave every editing component with a keyboard. Inspect shortcuts and their discoverability. Review the enhanced criteria separately from the minimum requirements.

A concrete example

A block editor offers a keyboard command to move the selected block, announces its new position and returns focus predictably. Dragging the block with a pointer is one supported input method.

W3C guideline and rationale · Implementation guidance

A.3.1.1 Level AKeyboard Access (Minimum)

W3C Recommendation excerpt · 24 September 2015

All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

  • Note 1: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard.
  • Note 2: The path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle.
  • Note 3: This success criterion does not forbid and should not discourage other input methods (e.g. mouse, touch) in addition to keyboard operation.
A.3.1.2 Level ANo Keyboard Traps

W3C Recommendation excerpt · 24 September 2015

If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface. If it requires more than unmodified arrow or tab keys or other standard exit methods, authors are advised of the method for moving focus away. (Level A)

A.3.1.3 Level AAEfficient Keyboard Access

W3C Recommendation excerpt · 24 September 2015

The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA)

A.3.1.4 Level AAAKeyboard Access (Enhanced)

W3C Recommendation excerpt · 24 September 2015

All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)

A.3.1.5 Level AAACustomize Keyboard Access

W3C Recommendation excerpt · 24 September 2015

If the authoring tool includes keyboard commands, then those keyboard commands can be customized. (Level AAA)

A.3.1.6 Level AAAPresent Keyboard Commands

W3C Recommendation excerpt · 24 September 2015

If the authoring tool includes keyboard commands,

then the authoring tool provides a way for authors to determine the keyboard commands associated with authoring tool user interface components. (Level AAA)

GUIDELINE A.3.2

Provide authors with enough time

Protect work when an author needs more time.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Observe session expiry, confirmation countdowns and autosave behavior using a disposable draft. Check that edits survive the relevant session limits and that each timing exception is justified from the actual criterion.

A concrete example

A CMS warns about expiry through an accessible message and preserves the draft. Test recovery after signing in again: the presence of an autosave icon alone does not prove that the latest text was retained.

W3C guideline and rationale · Implementation guidance

A.3.2.1 Level AAuto-Save (Minimum)

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not include session time limits or the authoring tool can automatically save edits made before the session time limits are reached. (Level A)

A.3.2.2 Level ATiming Adjustable

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not include time limits or at least one of the following is true: (Level A)

  • (a) Turn Off: Authors are allowed to turn off the time limit before encountering it; or
  • (b) Adjust: Authors are allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • (c) Extend: Authors are warned before time expires and given at least 20 seconds to extend the time limit with a simple action (e.g. "press the space bar"), and authors are allowed to extend the time limit at least ten times; or
  • (d) Real-time Exception: The time limit is a required part of a real-time event (e.g. a collaborative authoring system), and no alternative to the time limit is possible; or
  • (e) Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • (f) 20 Hour Exception: The time limit is longer than 20 hours.
A.3.2.3 Level AStatic Input Components

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not include moving user interface components that accept input where the movement of these components cannot be paused by authors. (Level A)

A.3.2.4 Level AAAContent Edits Saved (Extended)

W3C Recommendation excerpt · 24 September 2015

The authoring tool can be set to automatically save web content edits made using the authoring tool. (Level AAA)

GUIDELINE A.3.3

Help authors avoid flashing that could cause seizures

Give authors control over moving content during editing.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Load an editing view with a harmless animation or video fixture. Check the option to avoid automatic playback and the pause control before reviewing the rest of the content. Never use hazardous flashing as a test fixture.

A concrete example

A media editor opens a clip on a static frame. The author chooses when to play it and can pause while inspecting the timeline or editing a caption.

W3C guideline and rationale · Implementation guidance

A.3.3.1 Level AStatic View Option

W3C Recommendation excerpt · 24 September 2015

If an editing-view can play visual time-based content, then playing is not necessarily automatic upon loading the content and playing can be paused. (Level A)

GUIDELINE A.3.4

Enhance navigation and editing via content structure

Use content structure to support navigation.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

In a long draft, navigate between exposed markup elements and select them for editing. Where the tool edits programmatic relationships, try moving between the related objects and record the interaction.

A concrete example

An outline lets an author jump to a heading and select its section. A form editor also helps move from a control to the label it references, reducing repeated traversal of the whole document.

W3C guideline and rationale · Implementation guidance

A.3.4.1 Level AANavigate By Structure

W3C Recommendation excerpt · 24 September 2015

If editing-views expose the markup elements in the web content being edited, then the markup elements (e.g. source code, content renderings) are selectable and navigation mechanisms are provided to move the selection focus between elements. (Level AA)

A.3.4.2 Level AAANavigate by Programmatic Relationships

W3C Recommendation excerpt · 24 September 2015

If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. (Level AAA)

  • Note: Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships.

GUIDELINE A.3.5

Provide text search of the content

Help authors find the text they need to change.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Use a draft containing repeated words, a word embedded in a longer word and mixed case. Search forwards and backwards and inspect how the match is exposed, using the detailed success-criterion list as your reference.

A concrete example

An author searches a long policy draft for “access,” reaches each occurrence and can return to a previous match without losing the editing position.

W3C guideline and rationale · Implementation guidance

A.3.5.1 Level AAText Search

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides an editing-view of text-based content, then the editing-view enables text search, such that all of the following are true: (Level AA)

  • (a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
  • (b) Match: Matching results can be presented to authors and given focus; and
  • (c) No Match: Authors are informed when no results are found; and
  • (d) Two-way: The search can be made forwards or backwards.

GUIDELINE A.3.6

Manage preference settings

Separate personal editing preferences from published content.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Change the editor’s text size, colors or controls, then inspect the saved content. Close and reopen an authoring session and change a platform preference to check which personal settings persist or apply.

A concrete example

An author uses a larger, high-contrast editing view while the article’s saved CSS remains unchanged. The next editing session restores that personal view rather than rewriting the publication design.

W3C guideline and rationale · Implementation guidance

A.3.6.1 Level AIndependence of Display

W3C Recommendation excerpt · 24 September 2015

If the authoring tool includes display settings for editing-views, then the authoring tool allows authors to adjust these settings without modifying the web content being edited. (Level A)

A.3.6.2 Level AASave Settings

W3C Recommendation excerpt · 24 September 2015

If the authoring tool includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA)

A.3.6.3 Level AAApply Platform Settings

W3C Recommendation excerpt · 24 September 2015

The authoring tool respects changes in platform display and control settings, unless authors select more specific display and control settings using the authoring tool. (Level AA)

GUIDELINE A.3.7

Ensure that previews are at least as accessible as in-market user agents

Provide a useful route from editing to preview.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Identify whether the preview is inside the tool or delegated to another user agent. Try relevant keyboard and assistive-technology interactions, and check the options to choose an external preview user agent.

A concrete example

A CMS offers a preview link that opens the draft in a browser the author can use. Record any authentication or sharing conditions needed to reproduce that preview.

W3C guideline and rationale · Implementation guidance

A.3.7.1 Level APreview (Minimum)

W3C Recommendation excerpt · 24 September 2015

If a preview is provided, then at least one of the following is true: (Level A)

  • (a) In-Market User Agent: The preview renders content using a user agent that is in-market; or
  • (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines 1.0 Level A [UAAG10].
A.3.7.2 Level AAAPreview (Enhanced)

W3C Recommendation excerpt · 24 September 2015

If a preview is provided, then authors can specify which user agent performs the preview. (Level AAA)

A.4 Editing-views are understandable

GUIDELINE A.4.1

Help authors avoid and correct mistakes

Let authors recover from mistakes.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

With a disposable draft, delete a block, replace content and change an interface setting. Check reversal or confirmation at the minimum level, then inspect sequential undo for the enhanced criterion.

A concrete example

An author accidentally replaces an entire paragraph and can undo the action. A change that cannot be reversed has a clear confirmation before the loss happens.

W3C guideline and rationale · Implementation guidance

A.4.1.1 Level AContent Changes Reversible (Minimum)

W3C Recommendation excerpt · 24 September 2015

All authoring actions are either reversible or the authoring tool requires author confirmation to proceed. (Level A)

A.4.1.2 Level ASettings Change Confirmation

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides mechanisms for changing authoring tool user interface settings, then those mechanisms can reverse the setting changes, or the authoring tool requires author confirmation to proceed. (Level A)

A.4.1.3 Level AAAContent Changes Reversible (Enhanced)

W3C Recommendation excerpt · 24 September 2015

Authors can sequentially reverse a series of reversible authoring actions. (Level AAA)

GUIDELINE A.4.2

Document the user interface, including all accessibility features

Make the authoring interface learnable.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Find instructions for keyboard access, preferences, preview and other features used to meet Part A. Check where each feature is documented or otherwise described, and whether the instructions themselves are accessible.

A concrete example

A new keyboard user can find how to enter and leave the editing area and use the toolbar. A help page that merely says “click the icon” leaves a key authoring task unexplained.

W3C guideline and rationale · Implementation guidance

A.4.2.1 Level ADescribe Accessibility Features

W3C Recommendation excerpt · 24 September 2015

For each authoring tool feature that is used to meet Part A of ATAG 2.0, at least one of the following is true: (Level A)

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g. passing information to a platform accessibility service).
A.4.2.2 Level AADocument All Features

W3C Recommendation excerpt · 24 September 2015

For each authoring tool feature, at least one of the following is true: (Level AA)

  • (a) Described in the Documentation: Use of the feature is explained in the authoring tool's documentation; or
  • (b) Described in the Interface: Use of the feature is explained in the authoring tool user interface; or
  • (c) Platform Service: The feature is a service provided by an underlying platform; or
  • (d) Not Used by Authors: The feature is not used directly by authors (e.g. passing information to a platform accessibility service).

PART B

Support the production of accessible content

Part B conformance applicability notes W3C normative excerpt
  1. Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
  2. Developer control: The Part B success criteria only apply to the authoring tool as it is provided by the developer. This does not include subsequent modifications by parties other than the authoring tool developer (e.g. third-party plug-ins, user-defined templates, user modifications of default settings).
  3. Applicability after the end of an authoring session: Authoring tools are responsible for the web content accessibility (WCAG) of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author causes, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed).
  4. Authoring systems: As per the ATAG 2.0 definition of authoring tool, several software tools (identified in any conformance claim) can be used in conjunction to meet the requirements of Part B (e.g. an authoring tool could make use of a third-party software accessibility checking tool).
  5. Accessibility of features provided to meet Part B: The Part A success criteria apply to the entire authoring tool user interface, including any features that must be present to meet the success criteria in Part B (e.g. checking tools, repair tools, tutorials, documentation).
  6. Multiple authoring roles: Some authoring tools include multiple author roles, each with different views and content editing permissions (e.g. a content management system may separate the roles of designers, content authors, and quality assurers). In these cases, the Part B success criteria apply to the authoring tool as a whole, not to the view provided to any particular authoring role. Accessible content support features should be made available to any authoring role where it would be useful.
  7. Unrecognizable content: When success criteria require authoring tools to treat web content according to semantic criteria, the success criteria only apply when these semantics are encoded programmatically (e.g. text describing an image can only be considered a text alternatives for non-text content when this role is encoded within markup).

Read these notes in the Recommendation

B.1 Fully automatic processes produce accessible content

GUIDELINE B.1.1

Ensure that automatically-specified content is accessible

Treat automatically generated content as part of the product.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Inspect output created both during and after an authoring session: navigation, table markup, related-content panels or scheduled publishing. Check the precise alternatives and timing conditions in each criterion.

A concrete example

A CMS generates an article index overnight. Its links and structure are evaluated as generated output even though no author clicked Publish at that moment.

W3C guideline and rationale · Implementation guidance

B.1.1.1 A / AA / AAA · WCAG-dependentContent Auto-Generation After Authoring Sessions (WCAG)

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not automatically generate web content after the end of an authoring session, or, authors can specify that the content be accessible web content (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.1.1.2 A / AA / AAA · WCAG-dependentContent Auto-Generation During Authoring Sessions (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides the functionality for automatically generating web content during an authoring session, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
  • (a) Accessible: The content is accessible web content (WCAG) without author input; or
  • (b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or
  • (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the automatic generation process, the authoring tool prompts authors to perform accessibility checking.

GUIDELINE B.1.2

Ensure that accessibility information is preserved

Preserve accessibility information through transformations.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Create a fixture with headings, image alternatives, table headers and relationships. Copy it inside the tool, convert it to another supported format and run optimization separately; compare the information before and after each operation.

A concrete example

Pasting a figure into another article retains its alternative text. When a conversion cannot preserve a relationship, the workflow makes the limitation visible instead of silently dropping it.

W3C guideline and rationale · Implementation guidance

B.1.2.1 A / AA / AAA · WCAG-dependentRestructuring and Recoding Transformations (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides restructuring transformations or re-coding transformations, and if equivalent mechanisms exist in the web content technology of the output, then at least one of the following is true: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • (a) Preserve: Accessibility information (WCAG) is preserved in the output; or
  • (b) Warning: Authors have the default option to be warned that accessibility information (WCAG) may be lost (e.g. when saving a vector graphic into a raster image format); or
  • (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or
  • (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking.
B.1.2.2 A / AA / AAA · WCAG-dependentCopy-Paste Inside Authoring Tool (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.1.2.3 Level AOptimizations Preserve Accessibility

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides optimizing web content transformations, then any accessibility information (WCAG) in the input is preserved in the output. (Level A).

B.1.2.4 Level AText Alternatives for Non-Text Content are Preserved

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides web content transformations that preserve non-text content in the output, then any text alternatives for that non-text content are also preserved, if equivalent mechanisms exist in the web content technology of the output. (Level A).

  • Note: This success criterion only applies when the output technology is "included" for conformance.

B.2 Authors are supported in producing accessible content

GUIDELINE B.2.1

Ensure that accessible content production is possible

Allow authors to create the accessibility information they need.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Choose real output requirements: a page title, heading structure, image alternative, language or form label. Try to set them using the tool’s supported authoring methods and record any restriction that prevents the required output.

A concrete example

A visual form builder lets an author provide a programmatically associated label. A text label drawn near a field is not treated as equivalent unless the resulting relationship is encoded.

W3C guideline and rationale · Implementation guidance

B.2.1.1 A / AA / AAA · WCAG-dependentAccessible Content Possible (WCAG)

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not place restrictions on the web content that authors can specify or those restrictions do not prevent WCAG 2.0 success criteria from being met. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

GUIDELINE B.2.2

Guide authors to produce accessible content

Put accessible authoring choices where people work.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Compare the available ways to create a heading, image or control. Inspect how prominent the accessible option is and whether accessibility properties can be set with the same kind of editing interface used for other properties.

A concrete example

The image properties panel puts alternative text beside size and alignment. The author can provide it during the normal workflow without discovering a separate source-code-only route.

W3C guideline and rationale · Implementation guidance

B.2.2.1 A / AA / AAA · WCAG-dependentAccessible Option Prominence (WCAG)

W3C Recommendation excerpt · 24 September 2015

If authors are provided with a choice of authoring actions for achieving the same authoring outcome (e.g. styling text), then options that will result in accessible web content (WCAG) are at least as prominent as options that will not. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.2.2.2 A / AA / AAA · WCAG-dependentSetting Accessibility Properties (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides mechanisms to set web content properties (e.g. attribute values), then mechanisms are also provided to set web content properties related to accessibility information (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

GUIDELINE B.2.3

Assist authors with managing alternative content for non-text content

Support thoughtful alternatives for non-text content.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Add an image, edit its alternative, insert the same asset again and inspect any automatic suggestion. Check author control, confirmation and reuse against the individual conditions; judge wording in the context of each use.

A concrete example

A media library suggests a previously saved description but lets the author revise it for a linked image. It does not silently substitute the filename “IMG_1042.jpg” as a meaningful alternative.

W3C guideline and rationale · Implementation guidance

B.2.3.1 A / AA / AAA · WCAG-dependentAlternative Content is Editable (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides functionality for adding non-text content, then authors are able to modify programmatically associated text alternatives for non-text content. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

  • Note: An exception can be made when the non-text content is known to be decoration, formatting, invisible or a CAPTCHA.
B.2.3.2 Level AAutomating Repair of Text Alternatives

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not attempt to repair text alternatives for non-text content or the following are all true: (Level A)

  • (a) No Generic or Irrelevant Strings: Generic strings (e.g. "image") and irrelevant strings (e.g. the file name, file format) are not used as text alternatives; and
  • (b) In-Session Repairs: If the repair attempt occurs during an authoring session, authors have the opportunity to accept, modify, or reject the repair attempt prior to insertion of the text alternative into the content; and
  • (c) Out-of-Session Repairs: If the repair attempt occurs after an authoring session has ended, the repaired text alternatives are indicated during subsequent authoring sessions (if any) and authors have the opportunity to accept, modify, or reject the repair strings prior to insertion in the content.
B.2.3.3 Level AAASave for Reuse

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides the functionality for adding non-text content, when authors enter programmatically associated text alternatives for non-text content, then both of the following are true: (Level AAA)

  • (a) Save and Suggest: The text alternatives are automatically saved and suggested by the authoring tool, if the same non-text content is reused; and
  • (b) Edit Option: The author has the option to edit or delete the saved text alternatives.

GUIDELINE B.2.4

Assist authors with accessible templates

Help authors choose and maintain accessible templates.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Review the available template uses, how accessibility distinctions are shown and what happens when an author creates a template. Check the output of representative templates; keep the Level AAA requirement’s WCAG AA wording intact.

A concrete example

A CMS template chooser identifies which article and landing-page templates have been evaluated. The review records the tested versions and the author-supplied content still needed.

W3C guideline and rationale · Implementation guidance

B.2.4.1 A / AA / AAA · WCAG-dependentAccessible Template Options (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides templates, then there are accessible template (WCAG) options for a range of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.2.4.2 Level AAIdentify Template Accessibility

W3C Recommendation excerpt · 24 September 2015

If the authoring tool includes a template selection mechanism and provides any non-accessible template (WCAG) options, then the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)

  • Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.
B.2.4.3 Level AAAuthor-Created Templates

W3C Recommendation excerpt · 24 September 2015

If the authoring tool includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA)

  • Note: The distinction can involve providing information for the accessible templates (WCAG), the non-accessible templates or both.
B.2.4.4 Level AAAAccessible Template Options (Enhanced)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides templates, then all of the templates are accessible template (to WCAG Level AA). (Level AAA)

GUIDELINE B.2.5

Assist authors with accessible pre-authored content

Provide usable starting content.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Inspect reusable blocks, sample pages and other pre-authored content offered by the tool. Look for a range of accessible options and clear distinctions where the selection includes inaccessible options.

A concrete example

A component gallery offers an accessible contact form and a table with correctly associated headers. The author can distinguish those options while selecting a starting point.

W3C guideline and rationale · Implementation guidance

B.2.5.1 Level AAAccessible Pre-Authored Content Options

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides pre-authored content, then a range of accessible pre-authored content (to WCAG Level AA) options are provided. (Level AA)

B.2.5.2 Level AAIdentify Pre-Authored Content Accessibility

W3C Recommendation excerpt · 24 September 2015

If the authoring tool includes a pre-authored content selection mechanism and provides any non-accessible pre-authored content (WCAG Level AA) options, then the selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)

  • Note: The distinction can involve providing information for the accessible pre-authored content, the non-accessible pre-authored content or both.

B.3 Authors are supported in improving the accessibility of existing content

GUIDELINE B.3.1

Assist authors in checking for accessibility problems

Make checking understandable and tied to the content.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Run the tool’s checks on a draft with a missing alternative, ambiguous link text and a complex image. Inspect automatic findings and human-review prompts, how each item locates its content, and how the report handles uncertainty.

A concrete example

A checker links a missing-alternative finding to the exact image. For a chart description, it explains what the author must judge instead of presenting “alt present” as proof that the description is useful.

W3C guideline and rationale · Implementation guidance

B.3.1.1 A / AA / AAA · WCAG-dependentChecking Assistance (WCAG)

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides authors with the ability to add or modify web content in such a way that a WCAG 2.0 success criterion can be violated, then accessibility checking for that success criterion is provided (e.g. an HTML authoring tool that inserts images should check for alternative text; a video authoring tool with the ability to edit text tracks should check for captions). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.3.1.2 Level AHelp Authors Decide

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides accessibility checking that relies on authors to decide whether potential web content accessibility problems (WCAG) are correctly identified (i.e. manual checking and semi-automated checking), then the accessibility checking process provides instructions that describe how to decide. (Level A)

B.3.1.3 Level AHelp Authors Locate

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides checks that require authors to decide whether a potential web content accessibility problem (WCAG) is correctly identified (i.e. manual checking and semi-automated checking), then the relevant content is identified to the authors. (Level A)

  • Note: Depending on the nature of the editing-view and the scope of the potential web content accessibility problem (WCAG), identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.
B.3.1.4 Level AAStatus Report

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides checks, then authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA)

  • Note: The format of the accessibility status report is not specified and they might include a listing of problems detected or a WCAG 2.0 conformance level, etc.
B.3.1.5 Level AAProgrammatic Association of Results

W3C Recommendation excerpt · 24 September 2015

If the authoring tool provides checks, then the authoring tool can programmatically associate accessibility checking results with the web content that was checked. (Level AA)

GUIDELINE B.3.2

Assist authors in repairing accessibility problems

Help authors act on identified problems.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

For each type of problem the tool detects, follow its repair suggestion. Check that a relevant route to correction is available and verify the changed output, including cases that require human judgment.

A concrete example

A missing-label finding opens the corresponding field settings and explains how to supply a label. After saving, the author can inspect the resulting association and rerun the check.

W3C guideline and rationale · Implementation guidance

B.3.2.1 A / AA / AAA · WCAG-dependentRepair Assistance (WCAG)

W3C Recommendation excerpt · 24 September 2015

If checking (see Success Criterion B.3.1.1) can detect that a WCAG 2.0 success criterion is not met, then repair suggestion(s) are provided: (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.4 Authoring tools promote and integrate their accessibility features

GUIDELINE B.4.1

Ensure the availability of features that support the production of accessible content

Integrate accessibility support into everyday authoring.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Start with a fresh configuration. Inspect default support features, how to restore disabled features, any deactivation warning and their prominence compared with spelling or syntax tools.

A concrete example

Accessibility guidance is enabled for a new CMS account and appears in the normal publishing workflow. If an author disables a check, they can find the setting to restore it.

W3C guideline and rationale · Implementation guidance

B.4.1.1 Level AFeatures Active by Default

W3C Recommendation excerpt · 24 September 2015

All accessible content support features are turned on by default. (Level A)

B.4.1.2 Level AOption to Reactivate Features

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not include the option to turn off its accessible content support features or features which have been turned off can be turned back on. (Level A)

B.4.1.3 Level AAFeature Deactivation Warning

W3C Recommendation excerpt · 24 September 2015

The authoring tool does not include the option to turn off its accessible content support features or, if these features can be turned off, authors are informed that this may increase the risk of content accessibility problems (WCAG). (Level AA)

B.4.1.4 Level AAFeature Prominence

W3C Recommendation excerpt · 24 September 2015

All accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA)

GUIDELINE B.4.2

Ensure that documentation promotes the production of accessible content

Teach accessible practice through the tool’s own examples.

Try an authoring-tool review Original A11y.mv learning activity
Review activity

Review tutorials, code samples, screenshots and the help index. Follow an accessible authoring tutorial using the actual tool and compare its output with the practice the documentation describes.

A concrete example

The documentation’s image tutorial includes a context-appropriate alternative, demonstrates the relevant field and explains when an image is decorative. Its example can be followed without copying an accessibility error.

W3C guideline and rationale · Implementation guidance

B.4.2.1 A / AA / AAA · WCAG-dependentModel Practice (WCAG)

W3C Recommendation excerpt · 24 September 2015

A range of examples in the documentation (e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices (WCAG). (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

B.4.2.2 Level AFeature Instructions

W3C Recommendation excerpt · 24 September 2015

Instructions for using any accessible content support features appear in the documentation. (Level A)

B.4.2.3 Level AAATutorial

W3C Recommendation excerpt · 24 September 2015

The authoring tool provides a tutorial for an accessible authoring process that is specific to that authoring tool. (Level AAA)

B.4.2.4 Level AAAInstruction Index

W3C Recommendation excerpt · 24 September 2015

The authoring tool documentation contains an index to the instructions for using any accessible content support features. (Level AAA)

VERSION / LEVEL / SCOPE

How ATAG and WCAG work together

Keep the published requirement clear

ATAG 2.0’s normative wording refers to WCAG 2.0. WAI’s current overview encourages using the latest WCAG 2 version. Use WCAG 2.2 in a current product review, while recording the exact version and scope used; this companion preserves the ATAG standard’s original wording.

ATAG does not include WCAG’s accessibility-supported requirement. An evaluation of the published content’s WCAG conformance is independent of the tool’s ATAG conformance.

Read the normative WCAG relationship · WAI’s current ATAG overview

Read the level inside the criterion

There are 24 fixed A, 15 fixed AA and 11 fixed AAA criteria, plus 13 criteria with WCAG-dependent A/AA/AAA requirements. Those 13 are single criteria, not three separate entries.

A condition such as “if the tool provides templates” matters. A reference to WCAG AA inside a criterion does not automatically make it an ATAG AA criterion: B.2.4.4 is ATAG AAA and requires all provided templates to be accessible to WCAG AA.

A PRACTICAL WORKFLOW / ORIGINAL A11Y.MV GUIDANCE

Review a CMS from draft to publication

  1. Describe the system. Record the product and version, platform, included components, user roles, browsers and assistive technologies. Identify the web content technologies produced and those included or excluded from the proposed scope.
  2. Follow the author’s task. Create a draft, add structure and media, use dialogs, recover from a mistake and preview. Record reproducible Part A barriers, including barriers in accessibility-checking features.
  3. Follow the content. Inspect templates, generated output, copy-paste and conversion. Test guidance, checking and repair with examples requiring human judgment as well as automated checks.
  4. Decide applicability carefully. Record Yes, No or Not Applicable for each relevant criterion, with evidence and the criterion’s level. A conformance claim requires an explanation for every Not Applicable result; absence of a feature is not a blanket exemption.
  5. Report the limits. Keep the tool review and the output-content evaluation distinct. Include untested states, role or platform limitations, follow-up actions and the exact versions used. Involve authors with disabilities in real tasks.
Before making a conformance claim

Full conformance: Level A requires all applicable A criteria; AA adds applicable AA criteria; AAA requires all applicable criteria. Apply the normative notes for both parts. Reading a filtered list or completing these learning activities does not establish conformance.

Partial conformance: ATAG provides specific options for an authoring-process component that needs other components and for intrinsic platform limitations. These are scoped claims with conditions, not a general label for an unfinished audit.

Included technologies: A subset can be included, but it must include technologies the developer sets for automatically generated content and those set as defaults for author-generated content. A convenient sample alone cannot define away those defaults.

Claim details: Follow the standard’s required components, including date, guideline reference, level and type, authoring-tool information, included and excluded technologies, relied-on user agents and explanations for Not Applicable results. Record live-publishing support before, during and after a session where relevant.

Read all conformance requirements · Required claim components · Live publishing

Source, status and attribution

This independent software reference uses Authoring Tool Accessibility Guidelines (ATAG) 2.0, W3C Recommendation 24 September 2015. Source checked 15 September 2026. Follow the latest published ATAG 2.0, W3C errata and WAI overview for updates. Implementing ATAG 2.0 is informative supporting guidance, not another conformance standard.