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.
Review editing views, toolbars, dialogs, preferences, previews and help. Keyboard operation, perceivable information, recovery and documentation make content creation possible for more people.
Review generated markup, templates, alternative content, checking, repairs and teaching. Accessible authoring should be supported throughout the workflow, across relevant author roles.
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.
No matching success criteria
Try a shorter phrase, another part or reset the search and filters.
PART A
Make the authoring tool user interface accessible
Part A conformance applicability notes W3C normative excerpt
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).
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.
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).
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.
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)
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.
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.
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.
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.
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.
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)
All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)
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.
The authoring tool does not include sessiontime limits or the authoring tool can automatically save edits made before the session time limits are reached. (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.
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.
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)
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.
If editing-views expose the markupelements 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.
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.
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.
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.
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.
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.
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)
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.
Part B conformance applicability notes W3C normative excerpt
Author availability: Any Part B success criteria that refer to authors only apply during authoring sessions.
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).
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).
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).
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).
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.
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).
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.
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 generatingweb 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)
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.
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)
(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.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.
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)
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.
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)
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.
(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.
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.
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)
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.
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.
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)
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)
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.