# Assertions: A New Unit for Accessibility Evaluation > Learn about WCAG 3.0 Assertions compared to WCAG 2.2 conformance model. Discover the new standards for documenting accessibility processes and practical implementation strategies. **Published:** 2026-02-01 | **Updated:** 2026-02-01 --- ## Introduction In [Atomic Tests vs. Holistic Tests: A New Testing Methodology](/posts/wcag-3-atomic-holistic-tests/), 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](/posts/wcag-3-scoring-conformance/) 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. {{< img src="images/contents/og_bg_thumb.png" alt="Thumbnail image symbolizing WCAG 3.0 Assertions - visualizing documented accessibility procedures and accountability" caption="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 Foundational Requirements**. You can't claim conformance based on Assertions alone without meeting core requirements. {{< img src="images/contents/accessibility-process-log.jpg" alt="The process of recording and documenting accessibility procedures has become crucial." caption="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." {{< img src="images/contents/assertions-flow.png" alt="Diagram showing how test results and organizational procedures connect - the role of Assertions" caption="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**. {{< img src="images/contents/documentation-requirements.jpg" alt="You need to determine what items are required for Assertions documentation." caption="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. {{< img src="images/contents/team-accountability.jpg" alt="It's important for teams to discuss together and clarify accountability." caption="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" {{< img src="images/contents/process-strategy.jpg" alt="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." caption="Photo: Vitaly Gariev on Unsplash" >}} --- ## 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**. --- --- ## Other Posts in This Series - [The Dawn of WCAG 3.0: Why We Need New Guidelines]({{< relref "/posts/wcag-3-era-why-new-guidelines" >}}) - [WCAG 3.0 Structure Anatomy: From Success Criteria to Outcomes]({{< relref "/posts/wcag-3-structure-outcomes" >}}) - [WCAG 3.0 Conformance Model: Moving Beyond A/AA/AAA]({{< relref "/posts/wcag-3-scoring-conformance" >}}) - [Atomic Tests vs. Holistic Tests: A New Testing Approach]({{< relref "/posts/wcag-3-atomic-holistic-tests" >}}) - [WCAG 3.0 Expanded Scope: Beyond the Web]({{< relref "/posts/wcag-3-expanded-scope-beyond-web" >}}) ## References - [WCAG 3.0 Editor's Draft](https://w3c.github.io/wcag3/guidelines/) - Official W3C Document - [WCAG 3.0 Assertions](https://www.w3.org/TR/wcag-3.0-explainer/#assertions) - WCAG 3.0 Assertions - [WCAG 2.2](https://www.w3.org/TR/WCAG22/) - Current Recommendation - [Understanding Conformance](https://www.w3.org/WAI/WCAG22/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.