WCAG 2.2 explained: what changed and who is legally exposed

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, published by the W3C in October 2023. It adds nine success criteria to WCAG 2.1, retires one, and leaves everything else intact, so a site that already met 2.1 AA is most of the way there. Most accessibility law still names an earlier version of WCAG, but the guidelines are backwards compatible, so WCAG 2.2 Level AA is the sensible target for new work, and the case for reaching it is legal and commercial at the same time.

What actually changed in WCAG 2.2?

WCAG versions are backwards compatible. Everything you did for WCAG 2.0 and 2.1 still counts, with one exception: success criterion 4.1.1 Parsing was removed because modern browsers and assistive technologies no longer need it. The nine new criteria are additions, not rewrites, and they cluster around two groups of users that earlier versions served less well: people with motor impairments who find small or fussy controls difficult, and people with cognitive disabilities who are penalised by interfaces that demand memory, transcription and puzzle-solving.

Six of the nine new criteria sit at Level A or AA, which means they land inside the conformance target most laws and contracts reference. If your last audit was against WCAG 2.1 AA, those six criteria are the gap you need to close.

What do the new success criteria mean in plain terms?

Keeping focus visible

• Focus Not Obscured (Minimum), AA: when a keyboard user tabs to a control, sticky headers, cookie banners and chat widgets must not completely hide it. At least part of the focused element has to stay visible.
• Focus Not Obscured (Enhanced) and Focus Appearance, both AAA: stricter versions that ask for fully visible focus and a clearly sized, high-contrast focus indicator. Worth knowing about, rarely mandatory.

Making controls easier to operate

• Dragging Movements, AA: any action that relies on dragging, such as sliders, sortable lists or map panning, needs a single-pointer alternative like buttons or a text input. Tremors, limited dexterity and switch devices all make dragging unreliable.
• Target Size (Minimum), AA: interactive targets need to be at least 24 by 24 CSS pixels, or have equivalent spacing around them. Tiny icon buttons packed into toolbars are the usual offenders.

Reducing memory and effort

• Consistent Help, A: if you offer help, such as a phone number, contact link or chat, it should appear in the same relative place on every page.
• Redundant Entry, A: do not ask people to re-type information they already gave you earlier in the same process. Auto-populate it or make it selectable.
• Accessible Authentication (Minimum), AA: logging in cannot depend on a cognitive test such as recalling a password with pasting blocked, or solving a puzzle. Password managers, passkeys and emailed links are all acceptable routes. A companion AAA criterion tightens this further.

None of these demand exotic engineering. They demand attention during design and an honest pass over existing templates, which is why teams that build with accessibility in mind from the first sprint, the way we approach web app development, rarely find WCAG 2.2 painful.

Who is legally exposed, and under which law?

Accessibility law is a patchwork, but the direction is consistent: public bodies first, then large private organisations, then everyone who sells across a border. In Canada the two headline instruments are Ontario's Accessibility for Ontarians with Disabilities Act (AODA) and the federal Accessible Canada Act, with provincial acts such as the Accessible British Columbia Act following behind. American and European law matters more than many Canadian teams assume, because exposure follows your customers, not your head office.

Three practical readings of that table. First, if you are an Ontario organisation with fifty or more employees, web accessibility is already a filed-compliance matter, not a nice-to-have. Second, if you are federally regulated anywhere in Canada, you owe published accessibility plans, feedback processes and progress reports under the Accessible Canada Act. Third, if Americans can buy from your website, demand letters do not stop at the border, and web accessibility claims are common in the United States. Building to WCAG 2.2 AA meets or exceeds the technical benchmark in every row, because conformance is backwards compatible. It does not by itself discharge the separate duties to publish plans and reports.

How does an accessibility audit actually work?

A credible audit has layers, because no single method finds everything.

1. Scoping. Pick a representative sample: key templates, the highest-traffic pages, and every step of critical journeys such as checkout, booking or sign-up. Auditing every page of a large site is rarely useful; auditing every template is.
2. Automated scanning. Tools such as axe or Lighthouse catch machine-detectable issues: missing alt text, contrast failures, unlabelled form fields. This is the cheap layer, and also the shallow one. Automated tools flag only part of what real users run into, which is why a clean scan proves very little on its own.
3. Manual keyboard testing. An auditor puts the mouse away and works through every journey with Tab, Enter, Space and arrow keys, checking focus order, visible focus, keyboard traps and the new WCAG 2.2 focus-obscured criterion.
4. Screen-reader testing. Journeys are repeated with NVDA or JAWS on Windows and VoiceOver on Apple devices, because markup that looks fine can announce itself as nonsense.
5. Reporting and remediation. Findings are mapped to specific success criteria, given severity ratings, and turned into developer-ready tickets. A retest after fixes closes the loop, and many organisations publish an accessibility statement summarising the result.

An automated scan tells you a page is not obviously broken. Only a human with a keyboard and a screen reader can tell you whether it works.

Treat the audit as the start of a habit rather than a certificate. Sites change weekly, so accessibility checks belong in your development workflow, your component library and your definition of done, not in an annual scramble.

Does accessibility help the rest of the site?

The commercial argument is quieter than the legal one, and it rests on overlap rather than on any headline number. Permanent disability is only part of the picture: situational and temporary limits, such as a broken wrist, bright sunlight, a noisy commute or a slow connection, put almost every visitor in an accessibility-relevant situation at some point. Design for the hardest case and the average case gets easier.

The overlaps are direct. Bigger touch targets reduce mis-taps for everyone on mobile. Redundant Entry compliance shortens forms, so they ask less of the people filling them in. Accessible authentication removes login friction. Captions serve viewers in open-plan offices as well as deaf users. Semantic, well-structured HTML is what screen readers need and also what search engines and AI assistants parse best, so accessibility work and organic visibility work reinforce each other. When we run analytics and CRO engagements, accessibility defects and conversion leaks are often the same defects wearing different labels.

There is also a reputational side. Accessibility complaints are public, and remediation under deadline pressure interrupts everything else in a way that designing for it does not. The organisations that treat WCAG 2.2 as a design constraint, like performance or security, carry fewer surprises over the life of the site than those that treat it as an audit to pass.

How OlDevs helps

OlDevs is a full-stack technology studio in Vancouver, building for the web since 2014, and WCAG 2.2 AA is our default standard on every web development build, not an add-on. One accountable team designs, builds and tests with accessibility in the definition of done, you see a working demo every week, and you own all the code, designs, accounts and IP we produce. We work in English and French, and we serve clients across Canada and beyond remotely, with video calls in your time zone and on-site visits when the work calls for it.

Whether you need an audit of an existing site, remediation of known failures, or a new build that meets WCAG 2.2 AA from the first commit, tell us where you are and where the exposure sits. Request a quote and we will reply within one business day.