Assertions: A New Unit for Accessibility Evaluation

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.

Important: This post is based on the WCAG 3.0 Editor’s Draft (2026-01-05). The Draft is subject to change, and this document may be updated accordingly.

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 Foundational Requirements. You can’t claim conformance based on Assertions alone without meeting core requirements.

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.”

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.

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.

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”

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.

In the next post, we’ll look more specifically at what role Assertions play in the scoring model and how they combine with Foundational/Supplemental Requirements.

References

• WCAG 3.0 Editor’s Draft - Official W3C Document
• WCAG 3.0 Assertions - WCAG 3.0 Assertions
• WCAG 2.2 - Current Recommendation
• Understanding Conformance - WCAG 2.2 Conformance

Disclaimer: This post is based on the 2026-01-05 WCAG 3.0 Editor’s Draft. WCAG 3.0 is still under development, and content may change before the final recommendation. The conformance model in particular is not finalized, so please refer to the latest W3C documents.