Start with the content and the task
Use WCAG 2.2 to identify relevant success criteria, then test the complete journey. For custom controls, add a review of semantics, accessible names, states and keyboard behavior.
WAI REFERENCE LIBRARY
Choose the reference for what you build.
Accessible content depends on the tools that create it, the software that presents it, the way an interface communicates, and the quality of its testing and reporting. Explore the responsibilities together, then go deeper into the reference you need.
ONE EXPERIENCE / CONNECTED RESPONSIBILITIES
From making content to using it
- 01 / CREATE
Authoring tools
People with disabilities can use the editor, and the editor helps authors produce accessible content.
ATAG 2.0 → - 02 / PUBLISH
Content and interfaces
Pages, forms and media support people’s tasks. Interface code exposes meaning and state.
WCAG 2.2 WAI-ARIA → - 03 / PRESENT
Browsers and players
Software renders content, supports user preferences and works with assistive technology.
UAAG 2.0 → - 04 / USE
People and their tasks
Review the complete experience with people who have relevant access needs, across their tools and settings.
Record a task review →
An original learning map informed by W3C’s Essential Components of Web Accessibility. People with disabilities are both authors and users. Responsibilities overlap across this map.
START WITH YOUR TASK
What are you working on?
Review both sides of the authoring tool
ATAG Part A addresses authors using the tool. Part B addresses the tool’s support for producing accessible content. Include both the editing workflow and the published output.
- Explore ATAG Part A and Part B
- Choose representative author tasks: create, edit, check, repair and publish.
- Evaluate relevant web interfaces and output with WCAG
Review the software that presents content
UAAG helps you examine rendering, navigation, configuration and programmatic access. Define what the user agent, platform and any included extensions provide. A web player can also need a WCAG review of its interface.
- Explore the UAAG 2.0 Note
- Record the software version, platform, content and assistive technology used.
- Plan the media and playback review
Start with a native HTML control
When HTML already provides the behavior and meaning you need, use it. If you build a custom pattern, its semantics and interaction both need implementation and testing. Adding a role alone does not add keyboard behavior.
Make the test repeatable and its scope clear
ACT Rules Format helps test authors document the input, applicability, expectations and requirement mappings of a rule. Agree on what is being tested, then check consistent outcomes against examples.
- Explore ACT 1.1 and practise interpreting test evidence
- Browse W3C’s published ACT rules
- Learn how EARL represents an individual test result
A rule can cover only part of a requirement. A passing rule result does not establish that a page or site conforms to WCAG.
Keep the result connected to its evidence
EARL provides an RDF vocabulary for saying who or what evaluated a subject, which test was used, and what result was recorded. Use consistent identifiers and include enough context for another person or tool to interpret the assertion.
- Explore EARL and build an example assertion
- Review the test’s applicability and expectations
- Keep a readable worksheet of review steps and evidence
An exchange format does not verify the evidence or certify conformance. Agree on the receiving tool’s supported vocabulary and report structure.
Study the direction and keep the version visible
WCAG 3.0 is an incomplete Working Draft. Explore its topics, proposed requirements and model, while keeping draft observations separate from current technical evaluations.
EXPLORE THE FAMILY
References and supporting guidance
W3C RECOMMENDATION
WCAG 2.2
Web Content Accessibility Guidelines. Search the 86 success criteria, with plain-language explanations and checks.
Open the WCAG 2.2 reference →WORKING DRAFT / 10 SEP 2026
WCAG 3.0
W3C Accessibility Guidelines. Explore 216 draft provisions and original activities across 46 guideline headings.
Explore the WCAG 3 draft →WORKING GROUP NOTE / 15 DEC 2015
UAAG 2.0
User Agent Accessibility Guidelines. Explore guidance for browsers, readers, media players and their interaction with assistive technology.
Open the UAAG reference →W3C RECOMMENDATION / 24 SEP 2015
ATAG 2.0
Authoring Tool Accessibility Guidelines. Explore accessible editing interfaces and support for authors producing accessible content.
Open the ATAG reference →W3C RECOMMENDATION / 6 JUN 2023
WAI-ARIA 1.2
Accessible Rich Internet Applications. Explore roles, states and properties, with practical guidance for interface implementation.
Open the WAI-ARIA reference →W3C RECOMMENDATION / 5 FEB 2026
ACT Rules Format 1.1
Accessibility Conformance Testing. Understand rule structure, applicability, expectations and outcomes, then work through practical evidence cases.
Open the ACT reference →WORKING GROUP NOTE / 2 FEB 2017
EARL 1.0 Schema
Evaluation and Report Language. Explore the vocabulary for test results and build an assertion to export as Turtle or JSON-LD.
Open the EARL reference →INFORMATIVE W3C GUIDANCE
ARIA Authoring Practices Guide
Patterns, keyboard conventions and examples to help implement interfaces. The APG supports learning and implementation; it is separate from the normative ARIA specification.
Explore the official APG →FROM REQUIREMENT TO RECORDED RESULT
Connect testing with reporting
- 01 / DEFINE THE SCOPE
Requirement
Identify the criterion and version relevant to the task. Record the boundaries of the evaluation.
Explore WCAG 2.2 → - 02 / DESCRIBE THE CHECK
Test rule
Specify inputs, applicable targets and expectations. Explain how the outcome relates to a requirement.
Learn ACT rule structure → - 03 / EVALUATE
Evidence
Run the relevant checks and document observations, environment and any unresolved questions.
Use the testing worksheet → - 04 / EXCHANGE
Assertion
Identify the evaluator, subject, test and result in a machine-readable report that retains context.
Build an EARL assertion →
This is an original learning workflow. ACT rules and EARL reports can support evaluation; neither replaces the work needed to evaluate a complete experience.
See how the responsibilities meet
Original worked examples for discussing scope. They are starting points for a review, not conformance assessments.
Publishing a workshop announcement in a CMS
ATAG Part A: Can an author using a keyboard or screen reader reach the image picker, edit the text and publish?
ATAG Part B: Does the editor help the author supply an appropriate alternative, preserve it during edits, and check relevant accessibility problems?
WCAG: Does the published announcement communicate the image’s purpose and present the date, location and registration link accessibly?
UAAG and ARIA: Does the browser expose the relevant information to assistive technology? If the CMS uses a custom picker, are its name, role, state and interaction implemented correctly?
Building a player for recorded training
Content: Plan the relevant captions, transcript and description, then review their accuracy and availability.
Player: Review controls, keyboard use, configuration and how the software presents alternatives. UAAG provides guidance on user-agent responsibilities; WCAG remains relevant to a web player’s interface and content.
Implementation: Prefer suitable native controls. For a custom mute control, keep its accessible name or state consistent with its actual behavior and test it with assistive technology.
Adding tabs to an account interface
WCAG: People need to operate the interface, understand focus, and access the associated content.
WAI-ARIA: If a tab pattern is appropriate, communicate the tab, tab list, panel and selected state correctly.
Interaction: Implement the pattern’s keyboard movement, activation and focus behavior. Review the APG’s guidance and test the finished component in its page context. A role does not supply those behaviors.
Sharing a button-name finding with another team
Scope: Record the exact page state and button being examined. A name check is only one part of reviewing a usable control.
ACT: Read the selected rule’s applicability and expectations. Distinguish a target outside the rule’s scope from an applicable target that fails its expectations.
EARL: Reference that test and subject in an assertion, identify the evaluator and record the outcome with supporting observations. Keep uncertainty visible when evidence is incomplete.
Follow-up: The receiving team checks the evidence, repairs the issue and evaluates again. An exported result represents the recorded test, rather than a certificate for the site.
Practise interpreting outcomes · Create an example assertion
Read the status with the document
The source status matters: a Recommendation, a Working Group Note, a Working Draft and an informative guide have different roles. This library provides independent learning material and links to the original documents; it does not turn a Note or draft into a published standard.
Sources checked 15 September 2026: ATAG 2.0, UAAG 2.0, WAI-ARIA 1.2, APG, ACT Rules Format 1.1, EARL 1.0 Schema, and WAI’s standards overview. Each reference page identifies its source version and distinguishes original activities from source excerpts.
Continue the broader standards and frameworks lesson · Return to the digital accessibility hub