WCAG 2.2: Accessibility Checks for Modern Web Products

Accessibility is a product quality requirement: people should be able to understand and operate your application using different devices and assistive technologies. WCAG 2.2 provides testable guidance, including additions related to focus, target size, and accessible authentication. Build accessibility into research, components, and acceptance criteria rather than leaving it to a launch audit.

Test a complete task with a keyboard

Start with sign-in, navigation, search, forms, and checkout. Users need to see where focus is, reach every control, and escape overlays without getting trapped. Sticky headers and banners should not obscure the focused element. Custom widgets need appropriate semantics and keyboard behaviour.

Use native controls when they meet the requirement. A clickable div usually needs extra work to behave like a button. Test error messages and loading states as part of the task, not just the initial screen. A page may look accessible while a modal or validation step makes completion impossible.

Design understandable forms and authentication

Give fields persistent labels and explain required formats before submission. Associate errors with the relevant inputs, preserve entered values, and provide a way to identify what needs correction. Avoid instructions that rely only on colour or position.

Review password manager support, copy and paste, and alternatives to cognitive challenges. WCAG 2.2 accessible authentication criteria include important nuances and exceptions, so check the standard rather than applying a slogan. On touch devices, assess target size, spacing, and accidental activation around dense controls.

Combine automation with human verification

Automated checks find many markup and contrast issues, but they cannot establish whether a workflow is understandable or usable. Add manual keyboard testing, screen-reader checks, zoom testing, and research with people who use assistive technology. Record the browser and device combinations tested.

Maintain accessible components with documented behaviour and regression checks. When a component changes, test the journeys that depend on it. This article is implementation guidance, not a legal compliance determination; obligations depend on the organisation and jurisdiction, and should be reviewed with the appropriate specialists.

What to follow before development

• Define an accessibility target and the journeys in scope.
• Test visible, unobscured keyboard focus and overlay behaviour.
• Check labels, errors, zoom, contrast, and touch controls.
• Include assistive technology testing in release acceptance.

A practical example

A SaaS dashboard uses a sticky toolbar that covers focused filters after keyboard navigation. The team adjusts scroll spacing, verifies focus visibility at zoom, and retests the filter drawer with a screen reader. They document the component behaviour so the next dashboard does not reintroduce the same barrier.

Sources and further reading

• W3C Web Content Accessibility Guidelines 2.2

Plan your next step

Validate the workflow before committing to implementation with our UX/UI design team. For a related implementation guide, read design systems.