Introduction

In Atomic Tests vs. Holistic Tests: A New Testing Methodology, we discussed balancing Atomic and Holistic tests. Now we need to address how we’ll “assert” and “document” these results. This is where Assertions come in.

The scoring and conformance model covered in WCAG 3.0 Conformance Model: Changes After A/AA/AAA also connects with Assertions. This is because they provide a way to supplement areas not covered by quantitative tests with organizational processes and evidence.

Basis document: This post is based on the W3C Working Draft of March 3, 2026. Drafts are generally updated on roughly a six-month cycle, so details may vary depending on when you’re reading this.

Thumbnail image symbolizing WCAG 3.0 Assertions - visualizing documented accessibility procedures and accountability
Thumbnail image symbolizing WCAG 3.0 Assertions - visualizing documented accessibility procedures and accountability
Image: Generated with Nanobanana AI

What Are Assertions?

The WCAG 3.0 Explainer describes an Assertion as a documented statement by a responsible party declaring procedures undertaken to improve accessibility.

In other words, it’s not the test results themselves, but an organization’s declaration about the accessibility procedures they’ve performed. For example, the following could be Assertions:

  • Regular accessibility training was conducted
  • User testing (including assistive technologies) was performed and results were incorporated
  • A style guide for accessibility review is maintained and in use

Assertions cannot replace Core Requirements. You can’t claim conformance based on Assertions alone without meeting the core requirements. (Foundational was renamed to Core in the March 2026 draft.)

The process of recording and documenting accessibility procedures has become crucial.
The process of recording and documenting accessibility procedures has become crucial.
Photo: Gianluca Cinnante on Unsplash

Differences from WCAG 2.2

WCAG 2.2 doesn’t have an Assertions concept. Instead, it requires specific information in the Conformance Claim:

  • Conformance level (Level A/AA/AAA)
  • Standard version
  • Scope (pages/URL list)
  • Declaration date

WCAG 3.0’s Assertions go a step further by attempting to include organizational processes themselves in conformance. In other words, “how we maintain accessibility” becomes part of the evaluation scope.

Why Are Assertions Needed?

Some areas are difficult to explain with Atomic tests and automated tools alone:

  • Did you conduct user testing?
  • Were issues verified in real assistive technology environments?
  • Is accessibility review integrated into the content creation process?

These areas are hard to verify with isolated tests but significantly impact usability. WCAG 3.0’s direction is to surface these through Assertions.

Assertions are more like “recording organizational accountability and processes” rather than “test results.”

Diagram showing how test results and organizational procedures connect - the role of Assertions
Diagram showing how test results and organizational procedures connect - the role of Assertions
Image: Generated with Nanobanana AI

Assertions Documentation Requirements

The Draft document requires documentation items when using Assertions. Key items include:

  1. What’s being asserted (what was done)
  2. Assertion date
  3. Procedure performance period
  4. Scope (which products/services/processes it applies to)
  5. Responsible organization or personnel information
  6. Which Outcomes/Guidelines it supports

The important point is that Assertions are evaluated as True/False. In other words, “was it properly documented?” becomes the minimum standard.

Additional supporting documents are recommended but the Draft doesn’t make them mandatory requirements.

You need to determine what items are required for Assertions documentation.
You need to determine what items are required for Assertions documentation.
Photo: Zulfugar Karimov on Unsplash

Assertions Examples (Draft)

Here are examples reflecting the Draft’s intent:

Assertion A: Accessibility Testing Procedure

  • Content: “Between December 2025 and January 2026, we conducted 6 screen reader user testing sessions and incorporated all findings.”
  • Scope: Registration and payment processes
  • Responsible: Accessibility Team / QA Team
  • Supports: Related Outcomes and testing procedures

Assertion B: Content Style Guide

  • Content: “Our internal content style guide includes alternative text writing rules, and all editors follow these guidelines.”
  • Scope: Blog and marketing pages
  • Responsible: Content Team

Such Assertions can be used as supporting evidence in the scoring model.

It's important for teams to discuss together and clarify accountability.
It's important for teams to discuss together and clarify accountability.
Photo: Vitaly Gariev on Unsplash

Practical Implementation Strategy

Assertions are all about documentation quality. Here’s a stable approach:

  1. Start with documenting accessibility processes
    • Document training, review, and testing procedures
  2. Set narrow assertable scopes
    • Start with specific processes rather than the entire site
  3. Clearly record responsible parties
    • Make responsible organizations and contacts explicit
  4. Connect with quantitative test results
    • Ensure Assertions don’t appear as “empty claims”
A step-by-step approach is stable for practical Assertions implementation. It would be great to apply and design together on a shared canvas like a whiteboard.
A step-by-step approach is stable for practical Assertions implementation. It would be great to apply and design together on a shared canvas like a whiteboard.
Photo: Vitaly Gariev on Unsplash

One-page summary

  • An Assertion isn’t a test result — it’s a documented statement declaring the accessibility procedures an organization has actually carried out.
  • Assertions cannot replace Core Requirements — you can’t claim conformance through Assertions alone while failing to meet the core requirements.
  • WCAG 2.2 has no equivalent concept. It only requires a Conformance Claim with level, standard version, scope, and date.
  • Documentation covers six items — what’s asserted, date, performance period, scope, responsible party, and supported Outcomes — and the Assertion itself is judged True/False (supporting evidence is recommended, not required).
  • As of the March 2026 draft, Assertions total 28, and alongside Supplemental requirements they factor into “how much has been met” when a level is decided.
  • In practice, a stable approach starts with narrow scope (a specific process rather than the whole site), records the responsible party clearly, and ties Assertions back to quantitative test results.

Wrapping Up

WCAG 3.0’s Assertions represent an attempt to include not just accessibility “outcomes” but also “processes” in evaluation. This is a good direction, but it also requires documentation and accountability.

As of the March draft, Assertions have grown to 28, and alongside Supplemental they now factor into “how much has been met” when determining a level. See the conformance model post for the full structure.

References

Note: This post is based on the W3C Working Draft of March 3, 2026. WCAG 3 is still under development, so details may change before a final Recommendation, and the conformance model in particular is at the least mature stage within the draft. Check the original W3C document when you need an authoritative answer.