WCAG 2.2 in 2026: AA as the procurement bar, and why an overlay is not conformance

WCAG 2.2 is a technical accessibility standard organized around success criteria. It builds on earlier versions and adds criteria that matter for modern interfaces, including focus appearance, dragging movements, target size, redundant entry, accessible authentication, and help consistency. Most commercial programs aim for Level AA unless a contract says otherwise.

WCAG is not a single test tool and not a legal conclusion by itself. It is the engineering and design spec many laws, policies, RFPs, and VPATs refer to. Teams still need to understand their legal, contractual, and procurement obligations separately, but WCAG gives the product team something testable.

Good accessibility work covers templates, components, content, and end-to-end tasks. Marketing pages matter, but so do signup, checkout, billing, admin tables, dashboards, support forms, modals, mobile breakpoints, keyboard shortcuts, errors, and authentication flows. The user journey is the unit of confidence.

The checklist cannot decide which flows to test first. Teams should prioritize high-traffic, revenue-critical, legally sensitive, and user-blocking journeys before polishing low-use pages. A checkout or password reset defect may deserve immediate attention even if dozens of small content issues remain elsewhere.

It also cannot decide acceptable remediation patterns. For example, an icon-only button needs an accessible name, but the right fix may be visible text, an aria-label, a design-system change, or a broader interaction rewrite. A drag-and-drop feature may need keyboard alternatives, not just better instructions.

The checklist cannot replace judgment about assistive-technology coverage. Automated tools, manual keyboard testing, screen reader checks, zoom testing, browser combinations, and user research all reveal different issues. The mix should reflect product risk, customer commitments, release velocity, and how reusable the underlying component library is.

The classic failure is declaring victory from an automated 100 score. Scanners catch missing alt text, color contrast, obvious label problems, and structural issues, but they do not reliably prove keyboard usability, screen-reader flow, focus order, error recovery, or whether the product makes sense when navigated non-visually.

Scope is another trap. Teams remediate the marketing site because it is public, then leave the authenticated SaaS app, admin console, onboarding wizard, billing portal, and support knowledge base untouched. Enterprise buyers and users with disabilities care about the workflow they actually need to complete.

Modern UI details create real blockers. Icon-only controls without accessible names disappear to screen-reader users. CAPTCHA and copied-character authentication can block password managers and violate WCAG 2.2 accessible-authentication expectations. Custom components may look polished but lack focus states, role semantics, or keyboard behavior.

Start by defining scope as journeys, not pages. Choose representative flows, templates, and components across public and authenticated surfaces. Include mobile widths, error states, empty states, loading states, and authentication. Then use the checklist to test whether each flow meets the relevant WCAG 2.2 AA expectations.

For every checklist item, capture evidence that can survive review: screenshots, keyboard notes, screen-reader observations, automated-tool output, component tickets, design-system changes, and known exceptions. Accessibility evidence should be tied to releases so fixes do not vanish in the next redesign.

Treat the checklist as a recurring quality gate. Run it during design review, component release, QA, and major feature launches. This guide helps decide priorities and tradeoffs; the checklist converts those decisions into testable work that improves the product for real users.