Assertions

2 June 2025

Former work

• July 2024 Slide Deck
• Assertions Folder on Drive
• WCAG 3 Explainer - Section on Assertions
• Github Discussion 106
• Group Decisions
• Add assertions as exploratory 24 January 2023 Accept the new Assertions content as exploratory, acknowledging that the "what is a procedure" needs further definition.
• Level of assertions 17 January 2023 Bronze level would be where most 'outcome' based requirements will go, but we are not ruling out some assertions going at bronze level
• Documenting Assertions 17 January 2023 Limit the documentation required to information about the assertion itself. Recommend that organizations maintain documentation on the assertions.

Assertions (from explainer)

An Assertion is a formal claim of fact, attributed to a person or organization. In WCAG 3.0, an Assertion is an attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility.

Assertions may supplement Requirements to meet a Guideline. Not all Guidelines include Assertions. Guidelines that include Assertions, list the Assertions with the Requirements. Organizations can make an assertion that they followed a procedure as part of a conformance claim. Assertions can be made in addition to foundational requirements but do not replace foundational requirements.

Procedures used in assertions may be implemented at the organization level, during design and development, or during testing.

Outstanding questions with assertions

• How will WCAG 3 define procedures?
• Can steps in a procedure duplicate tests in other parts of the guidelines?
• How do we handle assertions that span guidelines?
• Can assertions be used at the foundational level (early decision hasn’t closed this)?
• At the supplemental level, can assertions be traded out for supplemental requirements?
• What does “documented” mean? Available publicly or published at all?
• What information should be included when documenting an assertion?
• What optional supporting documentation should organizations provide with an assertion?
• Is there a need for WCAG 3 to require proof of an assertion, and if so, what documentation should be required as proof?
• Should assertions be dated, expire, or be reviewed on a regular basis?
• Can assertions exist outside of conformance?
• For example, can they be used as an internal benchmark rather than for a claim of conformance?
• Can assertions be used to record accessibility work that is not required in the guidelines? This could include advance work on guidance not yet added to the guidelines.
• How can small organizations use assertions without unrealistic burden?
• Can assertions be used for conformance claims for large, complex, highly dynamic sites?
• Can we conduct implementation testing before we make these decisions?
• How do we know assertions are meaningful?
• How do we verify that the assertions are done in a way that improves accessibility?

Questions for today

• How do we handle assertions that span guidelines?
• What does “documented” mean? Available publicly or published at all?
• What information should be included when documenting an assertion?
• What optional supporting documentation should organizations provide with an assertion?
• Is there a need for WCAG 3 to require proof of an assertion, and if so, what documentation should be required as proof?
• Should assertions be dated, expire, or be reviewed on a regular basis?

Assertions identified so far

1. Assistive technology testing
2. Usability testing with people with disabilities
3. Plain language review
4. Use of a recognized security protocol
5. Style Guide

Examples from subgroup work (1 of 2)

• There is an organizational style guide that requires text-alternatives, and a policy that authors must follow this style guide.
• Internal Verification: The organization has a documented style guide which includes guidance on text-alternatives, and a policy that editors are required to follow the style guide. The style guide covers each type of image in the “Types of Image” section, and provides guidance and examples for authors to follow in their context.
• Structure follows an organizational design system.
• Internal Verification: The organization has a design system with guidelines for managing page structure and content, along with a policy requiring editors to adhere to it.

7

Examples from subgroup work (2 of 2)

• Private and sensitive information is handled according to [named security procedures] and reviews are conducted
• Criteria: The security procedure referenced must state how PII should be handled and warnings given to the user when sharing PII.
• Internal Verification: The organization follows and conducts verification testing against the named security procedure. The security procedure itself addresses how PII should be handled.

8

Suggested approach (1 of 2)

Normative

• Include a name and short description of each assertion that can be used within the conformance section.
• For each assertion, include the format for the statement and information that must be included.
• Link from here to a “How-to” for each assertion.
• Under each guideline, include the assertion(s) that can be used to support that guideline
• Note guideline-specific criteria that must be met (ex: Usability testing for help must include people with cognitive disabilities)
• Link to the assertion within the conformance section

Suggested approach (2 of 2)

Informative

• “How-to” documentation
• Best practices for meeting the assertion (similar way to techniques)
• Guideline specific criteria
• Links to related documentation, standards, etc.
• Additional detailed information could be available in a separate note.

Other

• Best practice information includes recommendations for internal documentation
• No public supplemental documentation or proof is required beyond the assertion statement but individuals/organization shso
• Suggestions on accepting assertions based on date or reviewing assertions can be included in a note with suggestions on how to use WCAG 3 for regulators.

​

What should an assertion statement include?

[Organization/person taking responsibility] assert that [on/between] [date(s) of process completion], we [process completed] on [scope of the assertions]. This assertion supports the following guidelines:

• [Guideline 1 name] - We assert that we met [guideline 1 specific criteria]
• [Guideline 2 name]
• [Guideline 3 name] - We assert that we met [Guideline 3 specific criteria]

FAQ

• How is an assertion and requirement different?
• A requirement can be tested and results verified.
• Example Requirement: That one does user testing of XYZ type
• An assertion is a statement. Only the fact that the assertion was made can be tested.
• Example Assertion: An assertion is made that user testing of XYZ type was done on dd/mm/yyy
• Where are assertions reported?
• Someplace public. Definitely in conformance reports; Likely also in accessibility statements
• Are assertions part of the conformance model?
• Yes, in the direction the AG is exploring, they can be used to meet Bronze and above levels of conformance
• Are assertions foundational or supplemental
• The AG seems to be leaning towards supplemental
• Should regulation point towards assertions?
• Not in WCAG 3.0 scope but this can be discussed as part of a note to policy makers