In Detail

What Are Assertions?

, from Notes # 6

In WCAG 3, some guidelines will not only cover requirements but also include the methods and procedures necessary for development and for making accessibility sustainable. These methods and procedures are called assertions. In his blog, Karl Groves defined assertions as “the most interesting and the most controversial idea in WCAG 3”. They are controversial because we do not yet know how an organization can document them or how assertions can be verified.

Even though there is a documentation and verification problem, some assertions can still be used as guidance for organizations. For example, the assertions in the Media Alternatives guideline describe clear steps. According to it, an organization should publish a media‑alternative style guide that specifies its policies for audio description, transcription, closed captioning, and sign‑language‑supported media. It should also address the accessibility of the video player. Since video players can be third‑party components, this is not included as a success criterion but as an assertion. Finally, the organization should state that alternative media (e.g., audio‑described video content) have been tested and reviewed by users and content authors.

Many of the assertions are about cognitive accessibility criteria. The test procedures for criteria related to clarity of page structure, plain language, error prevention, and consistency can be somewhat ambiguous. Here, with the assertions an organization can and should declare it has reviewed aspects such as the understandability of error messages or the structure of the page with users or guidance on related criteria. This creates an additional checkpoint for cognitive accessibility criteria.

In short, it is a good point that assertions focus on a process, emphasize the importance of user experience, and add additional checkpoints to hard-to-test criteria. Placing the assertions on the organization’s accessibility statement page can also solve the documentation problem. However, alongside all of this, the most important issue is the implementation of assertions by organizations, and I think this is somewhat difficult. In its current form, it appears to be an overwhelming process for organizations. Additional documentation is needed, such as the questions that could be asked during user reviews and what could be reviewed in internal review processes. Moreover, the distinction between the existing criteria and the assertions needs to be clarified. For example, it is not clear why we should assert separately if we already comply with the time‑limit success criteria. Situations like this create confusion. It may be early to say this, but the assertions could also be presented in a more compact and simple manner. For instance, grouping the assertions related to cognitive accessibility together could speed up the review process.

Discuss this article on LinkedIn