On 10 September 2026 the W3C published an updated Working Draft of WCAG 3.0. If you design interfaces, you probably want one answer: do I need to change anything? No. Keep designing to WCAG 2.2 AA. But the draft does show where accessibility is heading, and WCAG 2.2 already contains a handful of rules that many designs still fail on screen.
What the draft is, and what it is not
The draft itself is blunt. It says it still has "several years of work" ahead, that WCAG 3 is a successor to WCAG 2.2 "but does not deprecate WCAG 2", and that "details will change." It only includes requirements that have reached "developing status".
One line matters for anyone who picks colours: "The contrast algorithm used in WCAG 3 is yet to be determined." So do not rebuild your palette around a new contrast method. The decision has not been made.
AbilityNet, in a guide dated February 2026, gives the same advice. It says organisations "should continue to treat WCAG 2.2 as the de facto standard" and expects that a site conforming to WCAG 2.2 AA will likely align with the core of WCAG 3. It also says the guidelines are unlikely to be finalised before 2028.
What does change in how you think
Three shifts are worth absorbing now, according to AbilityNet's summary.
Views and processes, not pages. You will be judged on whole journeys such as checkout or sign-up, not on a single screen.
Layers instead of pass or fail. The conformance model moves towards several tiers of reporting.
More attention to cognitive access. One example in the draft work: explanations or unambiguous alternatives for non-literal language, like idioms and metaphors.
In design terms, you test a flow with a keyboard and a screen reader from start to finish, rather than ticking each frame.
AbilityNet also mentions "assertions", a layer meant to reward wider commitments such as staff training and testing with assistive technology. That fits team habits better than it fits any single screen, and it is a reason to write your accessibility practice down now, while it is cheap to do.
Five WCAG 2.2 rules to design for today
WCAG 2.2 added nine success criteria. These five are the ones a designer can fix before developers touch the code.
1. Target Size (Minimum), level AA
Interactive components need a target of at least 24 by 24 CSS pixels, except inline ones such as links in a sentence. Picture a toolbar with edit, copy and delete icons drawn 16 pixels wide with 4 pixels between them. Each icon can stay 16 pixels, but the tappable area around it must grow to 24.
2. Focus Not Obscured (Minimum), level AA
When a component gets keyboard focus, it must not be entirely hidden by content you added. The classic failure is a sticky header or cookie banner that covers the field being tabbed into. Design the header height into the layout, and ask developers to reserve space for it:
html {
scroll-padding-top: 5rem; /* height of the sticky header */
}3. Dragging Movements, level AA
Anything you can do by dragging needs a single-pointer alternative. A kanban board where cards only move by drag fails. Add a "Move to…" menu on each card.
4. Accessible Authentication (Minimum), level AA
Signing in should not depend on a cognitive function test such as memorising or transcribing. In practice: allow password managers and pasting, and offer another route if you use a puzzle.
5. Consistent Help and Redundant Entry, level A
Put the help link, chat or contact option in the same relative place on every screen of a flow. And do not ask users to type the same information twice in one process, such as a shipping address that has to be re-entered for billing.
If I had to pick two to fix first, I would choose target size and sticky headers. Both fail silently in a design file and only show up when someone uses a thumb or a keyboard.
A 15-minute test for any screen
Put the mouse aside and press Tab through the whole screen. Is there always a visible focus indicator? Does a header or banner ever cover it?
Find your smallest tappable things, such as close icons and row actions. Measure the clickable area, not the icon drawing.
Find anything that works by dragging: sliders, sortable lists, maps. Check that a button or menu does the same job.
Sign in with a password manager, then try pasting a password. If either is blocked, that is a barrier.
Look for the help link on three screens of the same flow. It should sit in the same relative spot each time.
A housekeeping note from the WCAG 2.2 page: criterion 4.1.1 Parsing is marked obsolete and removed, so it no longer needs checking. Spend the saved time on the list above.
What to do this quarter
Pick your three most important flows, such as onboarding, checkout and account recovery, and check each against the five items above.
Add a minimum hit area and a scroll-padding value to your design tokens so every component inherits them.
Record the decision: "We build to WCAG 2.2 AA; we are watching WCAG 3."
If you want a say, the W3C invites comments on the draft by email to wai@w3.org or through GitHub.
The takeaway: WCAG 3 is a direction, not a deadline. Spend this quarter fixing what WCAG 2.2 already asks for. When the new standard settles, a team that has already tested whole journeys will have little to relearn.