WCAG 2.2: use the new standard to improve the design review process

W3C published WCAG 2.2 as a Recommendation on October 5, 2023. For teams building business websites, a new version of the accessibility standard was a useful moment to revisit how accessibility work was organized. The practical opportunity was broader than adding another checklist at launch. It was to make inclusive interaction part of ordinary design, development, and content decisions.

A website is experienced as a sequence of tasks, not as a collection of compliance statements. Someone may need to open a menu, compare a service, complete a form, and recover from an error. If one step is difficult or unavailable, the quality of the surrounding pages does not resolve that barrier. Review should therefore follow complete journeys as well as individual components.

Put accessibility into the brief

Define the intended accessibility target and the scope of evaluation at the beginning of the project. Identify responsibilities for design, implementation, content, and third-party tools. A booking system embedded on the site can affect the customer journey even if another vendor maintains it. Those dependencies should be visible before the final review.

Include accessibility considerations in acceptance criteria for components. A menu needs more than an approved appearance; it also needs understandable controls and predictable keyboard behavior. A form needs labels, instructions, and useful error recovery. Writing those expectations down gives the team a shared basis for reviewing the finished work.

Test interaction, not only appearance

Use a keyboard to move through important tasks and inspect whether focus remains visible and logical. Review forms with errors, expanded menus, dialogs, and other states that may not appear in design mockups. An interface can work in its default state and fail when a visitor needs help or makes a mistake.

Consider an illustrative inquiry form with several required fields. If an error message appears far from the problem and the visitor cannot easily identify the field, the process becomes unnecessarily difficult. The solution may involve clearer instructions and better association between the message and the control, not simply a different color.

Combine automated checks with human review

Automated tools can help identify some issues, but their results are not a complete evaluation of the experience. They cannot fully determine whether an instruction makes sense, whether a sequence is confusing, or whether the content supports the user's task. Treat tool findings as one source of evidence rather than a certificate that the website is accessible.

Include people with relevant accessibility expertise and, where possible, users with different access needs. Plan enough time to investigate findings and retest corrections. A rushed final audit may identify important work after the project budget has already been exhausted. Earlier review allows issues to be resolved while the design is still flexible.

Maintain the gains after launch

Content changes can introduce barriers even when the original templates were carefully built. Train editors to use headings, links, images, and documents appropriately. Provide examples that match the site's actual content rather than relying entirely on a generic manual. Make review part of the publishing process.

Accessibility standards and legal obligations are not interchangeable, and a project-specific assessment may require specialist advice. From a design perspective, the essential commitment is ongoing: define responsibilities, test complete tasks, document findings, and maintain the experience. The release of WCAG 2.2 was a milestone, but dependable accessibility work requires habits that continue long after a version number changes.