ATAG

The Authoring Tool Accessibility Guidelines, commonly known as ATAG, explain how to
design authoring tools that are accessible to creators with disabilities and that
help all creators produce accessible web content.

Authoring tools shape much of the modern web. Content management systems, website
builders, learning platforms, visual editors, document converters, social networks
and AI-assisted creation tools all influence whether the content they generate is
accessible.

When accessibility is built into these tools, authors can create better content
without needing specialist knowledge for every decision. When accessibility support
is missing, the same barriers can be reproduced across thousands of pages,
documents and digital products.

What is ATAG?

ATAG stands for Authoring Tool Accessibility Guidelines. It is a technical standard
developed by the World Wide Web Consortium Web Accessibility Initiative.

ATAG 2.0 provides requirements for authoring tools that:

• Can be used by authors with disabilities.
• Generate accessible web content.
• Preserve accessibility information during editing and conversion.
• Help authors identify accessibility problems.
• Support authors in correcting accessibility problems.
• Promote accessible templates, components and workflows.

What is an authoring tool?

An authoring tool is software or a service that people use to create, edit, publish
or manage web content.

Authoring tools can include:

• Content management systems.
• Website builders.
• HTML and code editors.
• Visual page builders.
• Learning management systems.
• Course-authoring platforms.
• Blogging platforms.
• Social-media platforms.
• Online forums and community systems.
• Document and presentation software that exports web content.
• Multimedia-editing tools.
• Form builders.
• Email-template editors.
• AI-assisted content-generation tools.
• Design systems and component builders.

Who is ATAG for?

ATAG is primarily intended for organisations and teams that design, develop,
purchase or evaluate authoring tools.

Relevant audiences include:

• Software developers.
• Product managers.
• User-experience designers.
• Accessibility specialists.
• CMS and website-builder vendors.
• Learning-platform providers.
• Procurement teams.
• Government organisations.
• Universities and education providers.
• Organisations selecting publishing platforms.
• Policy makers and standards teams.

The two parts of ATAG 2.0

ATAG 2.0 is divided into two complementary parts.

A tool can produce accessible content while still being inaccessible to an author
with a disability. It can also have an accessible interface while generating
inaccessible content.

Complete ATAG alignment requires addressing both parts.

Part A: Making the authoring tool accessible

Part A focuses on the accessibility of the tool’s own user interface.

This may include the editor, toolbar, settings, dialogs, media library, preview,
publishing controls, help documentation and error messages.

A1: Follow accessible user-interface standards

Web-based authoring interfaces should follow applicable web accessibility
requirements. Non-web software should follow the accessibility conventions and
platform standards relevant to its operating environment.

Common requirements include:

• Keyboard access.
• Accessible names and labels.
• Logical focus order.
• Visible focus indicators.
• Sufficient contrast.
• Screen-reader compatibility.
• Accessible forms and errors.
• Support for text enlargement.

A2: Make editing views perceivable

Authors must be able to perceive the content and controls displayed in editing
views.

Examples include:

• Supporting platform display settings.
• Allowing text enlargement.
• Providing accessible alternatives for visual information.
• Keeping editing controls distinguishable.
• Ensuring that selection and focus are perceivable.

A3: Make editing views operable

Authors should be able to operate editing functions using supported input methods,
including keyboard and assistive technologies.

Relevant functions may include:

• Selecting and editing text.
• Adding headings and links.
• Uploading and describing images.
• Editing tables.
• Reordering content.
• Opening menus and dialogs.
• Saving, previewing and publishing.
• Undoing and correcting changes.

A4: Make editing views understandable

The interface should help authors understand what actions are available and recover
from mistakes.

This can include:

• Consistent navigation and controls.
• Clear labels and instructions.
• Understandable error messages.
• Help for complex accessibility features.
• Documentation of keyboard commands.
• Warnings before destructive actions.

Part B: Supporting the production of accessible content

Part B focuses on how the tool helps authors create accessible output.

The goal is not merely to permit accessible content. The tool should actively
support, guide and encourage accessible authoring.

B1: Automatic processes should produce accessible content

When the tool automatically generates markup, components, templates or media
structures, the result should be accessible.

Examples include:

• Generating semantic headings.
• Using native buttons for actions.
• Associating form labels correctly.
• Producing valid table structures.
• Preserving alternative text during conversion.
• Maintaining document language information.
• Avoiding inaccessible default components.

B2: Help authors create accessible content

The authoring tool should guide authors at the point where accessibility decisions
are made.

Examples include:

• Requesting alternative text when an image is added.
• Explaining when an image should be marked decorative.
• Providing accessible heading options.
• Warning against vague link text.
• Offering accessible colour combinations.
• Providing accessible form components.
• Supplying accessible templates.
• Supporting captions and transcripts for media.

B3: Help authors improve existing content

Authoring tools should help authors identify and repair accessibility problems in
existing content.

This may involve:

• Automated accessibility checks.
• Manual-review prompts.
• Clear descriptions of the affected content.
• Guidance explaining why the issue matters.
• Suggested repair options.
• Previewing the corrected result.
• Rechecking after remediation.

B4: Promote accessibility features

Accessibility functionality should be easy to find, understand and use.

It should not be hidden in advanced settings or documented only for accessibility
specialists.

The tool can promote accessible authoring by:

• Including accessibility in onboarding.
• Making accessible options the default.
• Integrating checks into normal publishing workflows.
• Providing accessible templates prominently.
• Explaining accessibility in contextual help.
• Including accessibility in product documentation and training.

ATAG conformance levels

ATAG success criteria are organised into three conformance levels:

A conformance claim must identify the tool, version, platform, scope and conformance
level being evaluated.

ATAG and WCAG

ATAG and WCAG address different parts of the digital-content process.

ATAG 2.0 references WCAG 2.0 because that was the current WCAG version when ATAG was
completed.

W3C states that ATAG remains relevant because it is technology agnostic and
recommends using the latest version of WCAG 2 when developing and evaluating modern
authoring tools.

Learn more about the
Web Content Accessibility Guidelines.

ATAG and UAAG

ATAG is also part of a broader group of W3C accessibility standards.

• WCAG addresses the accessibility of web content.
• ATAG addresses tools that create web content.
• UAAG addresses browsers, media players and other user agents that render content.

Accessible digital experiences depend on all of these components working together:
content, authoring tools, browsers, assistive technologies and users.

Content management systems

A content management system can have a major influence on website accessibility
because many authors depend on its default components and publishing controls.

An ATAG-informed CMS should:

• Provide an editor that works with keyboards and screen readers.
• Generate semantic HTML.
• Offer accessible heading and list controls.
• Prompt authors for useful alternative text.
• Support decorative-image handling.
• Provide accessible table creation.
• Warn about inaccessible links and colour combinations.
• Preserve accessibility information during editing.
• Include accessibility checks before publication.
• Provide accessible previews.

No-code and website-building platforms

No-code platforms allow users without development experience to create websites and
applications. Their defaults can either prevent or reproduce accessibility barriers.

Important features include:

• Accessible templates.
• Semantic component output.
• Keyboard-accessible editing controls.
• Clear heading structure.
• Accessible forms.
• Responsive text enlargement and reflow.
• Accessible navigation patterns.
• Warnings before publishing inaccessible content.

A platform should not require authors to modify generated source code merely to
achieve basic accessibility.

Learning management systems

Learning management systems are both authoring environments and delivery platforms.

They should allow instructors with disabilities to create and manage courses while
also helping all instructors produce accessible learning materials.

Relevant areas include:

• Course creation.
• Assignment and quiz builders.
• Multimedia uploads.
• Document conversion.
• Discussion forums.
• Grade and feedback tools.
• Course previews.
• Accessible templates.
• Accessibility checking.

Social media and user-generated content

Social platforms and community systems are authoring tools because users create and
publish content through them.

Accessibility support can include:

• Alternative-text fields for uploaded images.
• Automatic captions that authors can review and correct.
• Accessible post composers.
• Clear heading and list formatting.
• Accessible emoji and media controls.
• Warnings about inaccessible colour contrast.
• Accessible previews before publication.

AI-assisted authoring tools

AI tools increasingly generate text, code, images, interfaces, forms and complete
websites. These systems function as authoring tools when their output is intended
for publication on the web.

An ATAG-informed AI authoring tool should:

• Generate semantic HTML by default.
• Use native controls before custom ARIA patterns.
• Produce accessible names for generated controls.
• Avoid inventing inaccurate alternative text.
• Ask authors to review context-dependent accessibility decisions.
• Preserve accessibility information during regeneration.
• Explain accessibility problems in understandable language.
• Allow authors to approve or reject suggested repairs.
• Verify generated output rather than assuming it is accessible.

AI-generated code can appear correct while containing keyboard, focus, semantic or
behavioural barriers. Human review and functional testing remain necessary.

Accessible templates and components

Templates and reusable components are one of the most effective ways to support
accessible content production.

Accessible authoring tools should:

• Provide accessible templates by default.
• Identify accessibility limitations in templates.
• Prevent authors from unknowingly breaking essential semantics.
• Preserve labels, headings and relationships during editing.
• Retest components after platform updates.

When a shared template contains an accessibility problem, the barrier may appear
across every page created from it.

Alternative-text workflows

A simple alternative-text field is useful but does not guarantee meaningful image
descriptions.

An effective authoring tool should help the author decide:

• Whether the image is informative or decorative.
• What purpose the image serves in context.
• Whether nearby text already provides the information.
• Whether a complex image requires a longer description.
• Whether automatically generated text is accurate.

The tool should preserve approved alternative text when images are resized, moved,
converted or republished.

Accessibility checking and repair

Accessibility checks should be integrated into the normal authoring workflow rather
than offered only as a separate specialist tool.

A useful checker should:

• Identify the affected content.
• Explain the potential user impact.
• Distinguish definite failures from issues requiring review.
• Provide repair guidance.
• Avoid changing meaning without author approval.
• Allow the author to verify the corrected result.
• Preserve a record of unresolved issues.

Automatic accessibility repairs

Some accessibility problems can be corrected automatically, while others require
human judgement.

Potentially safe automatic corrections may include:

• Preserving existing accessibility metadata.
• Correcting invalid structural markup where meaning is clear.
• Applying accessible default templates.
• Restoring required labels already available in the content.

Human review is usually needed for:

• Alternative-text meaning.
• Heading purpose.
• Link purpose.
• Form instructions.
• Complex ARIA patterns.
• Keyboard interaction.
• Focus management.
• Captions and audio descriptions.

Preserving accessibility information

Authoring tools should not remove accessibility information when content is edited,
copied, imported, exported or converted.

Information that may need to be preserved includes:

• Alternative text.
• Heading structure.
• Table headers.
• Document language.
• Form labels.
• Captions.
• ARIA relationships.
• Reading order.

Conversion between formats should be tested because accessible source content can
become inaccessible during export.

Accessible previews

Authors with disabilities need access to previews so they can review the content
before publication.

A preview should:

• Be keyboard operable.
• Work with assistive technologies.
• Represent the published result accurately.
• Allow authors to return to the relevant editing location.
• Communicate errors and warnings clearly.

Common authoring-tool barriers

• The editor toolbar cannot be operated with a keyboard.
• Formatting controls have no accessible names.
• Drag-and-drop is the only method for rearranging content.
• The image uploader does not support alternative text.
• The tool generates nonsemantic buttons and links.
• Accessibility metadata disappears during editing.
• Templates contain repeated contrast or heading failures.
• The accessibility checker reports technical codes without useful guidance.
• Automatic fixes change content meaning without author approval.
• The preview cannot be used with a screen reader.
• Accessibility options are hidden in advanced settings.

How to evaluate an authoring tool

1. Define the authoring workflow:
   identify how users create, edit, review, preview and publish content.
2. Identify author groups:
   include authors using keyboards, screen readers, magnification and other
   assistive technologies.
3. Assess the interface:
   test the tool against relevant Part A requirements.
4. Review generated output:
   assess whether templates and automatic processes create accessible content.
5. Test author guidance:
   determine whether the tool supports accessible decisions at the correct time.
6. Test checking and repair:
   review how findings are explained, corrected and verified.
7. Test import and export:
   confirm that accessibility information is preserved.
8. Document results:
   record the product version, platform, scope, findings and evidence.

ATAG procurement checklist

Organisations purchasing an authoring tool should ask vendors:

• Can authors operate every feature using a keyboard?
• Has the tool been tested with screen readers?
• Does it generate semantic and valid output?
• Are accessible templates included by default?
• Does it prompt for alternative text and captions?
• Does it identify accessibility problems before publication?
• Can authors review and approve suggested repairs?
• Is accessibility metadata preserved during import and export?
• Is an ATAG conformance report available?
• How are accessibility defects prioritised and corrected?

ATAG reporting

W3C provides an ATAG Report Tool that guides evaluators through the requirements and
helps generate an evaluation report.

A useful report should identify:

• The product and version evaluated.
• The operating environment.
• The authoring functions included.
• The ATAG conformance level assessed.
• The testing methods used.
• Supported and unsupported requirements.
• Known limitations.
• Required author actions.

How Pluro supports accessible authoring workflows

Pluro is an accessibility workflow platform that helps teams identify, manage and
verify accessibility barriers across websites and digital products.

Authoring-tool and platform teams can use Pluro to:

• Centralise automated and manual findings.
• Capture evidence from generated content.
• Identify repeated problems in templates and components.
• Assign findings to product, engineering, design or content teams.
• Provide remediation guidance.
• Verify corrections before findings are closed.
• Monitor output after future platform releases.

Pluro does not automatically certify an authoring tool against ATAG. A complete ATAG
assessment must evaluate both the accessibility of the authoring interface and the
tool’s support for producing accessible content.

ATAG 2.0 checklist

• Make the authoring interface accessible to creators with disabilities.
• Provide keyboard access to all authoring functions.
• Support assistive technologies.
• Generate accessible content by default.
• Preserve accessibility information during editing and conversion.
• Provide accessible templates and components.
• Guide authors when accessibility decisions are required.
• Check existing content for accessibility problems.
• Help authors repair identified issues.
• Require review for context-dependent automatic fixes.
• Provide accessible previews and documentation.
• Promote accessibility as part of the standard workflow.
• Retest after platform and template updates.

Important notice

This page provides general information and does not constitute legal advice or a
formal ATAG conformance assessment. Requirements depend on the authoring tool,
platform, features, output and scope of the evaluation.

Review the official

Authoring Tool Accessibility Guidelines 2.0
.

Read the

W3C ATAG overview
.

See how Pluro manages accessibility workflows
or
start a 14-day free trial
with no credit card required.