Accessibility in UI and UX Design for 2026
Anurag Kurmi
Senior Full Stack Engineer, Unico Connect
In this article
Accessibility stopped being a matter of conscience and became a matter of dates. In the United States it is a procurement requirement with a deadline attached. In the European Union it has been law since June 2025. Buyers now ask for evidence, and a designer who cannot produce it costs the company the deal.
There is also a detail almost every article on this subject gets wrong, and it will shape what your team builds. The US regulation mandates WCAG 2.1 Level AA. The current W3C standard is WCAG 2.2, published as a Recommendation in December 2024, which adds nine success criteria that 2.1 does not contain. Build strictly to the regulation and you ship against a superseded standard. Build to 2.2 and you satisfy both.
This guide explains which rules actually bind you, what the newer criteria demand of designers specifically, and the handful of design decisions responsible for most real failures.
Quick Answer
Design to WCAG 2.2 Level AA. It is the current W3C standard, published 12 December 2024, and it is a superset of WCAG 2.1 Level AA, which is what the Americans with Disabilities Act title II rule requires of US state and local government entities including school districts. Those title II deadlines moved in April 2026 and are now 26 April 2027 for entities serving a population of 50,000 or more and 26 April 2028 for smaller entities and special district governments. In the European Union the European Accessibility Act has applied since 28 June 2025, underpinned by the harmonised standard EN 301 549. WCAG 2.2 adds nine criteria over 2.1, of which six sit at Level A or AA and are therefore work your team has to do. The failures we see most often are not exotic. Contrast, focus order, target size, error handling in forms, and content that only exists as an image.
Key Takeaways
- The regulation and the standard are different versions, and that matters. ADA title II names WCAG 2.1 Level AA. The current W3C Recommendation is WCAG 2.2. Designing to 2.2 covers both, since it contains everything 2.1 requires at the same levels.
- Six of the nine new criteria are at A or AA. Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum) and Accessible Authentication (Minimum) are AA. Consistent Help and Redundant Entry are A. The remaining three are AAA and optional for most teams.
- Target Size (Minimum) is a hard number. Pointer targets must be at least 24 by 24 CSS pixels, with five defined exceptions. This is the criterion most likely to force a change to an existing design system, because dense toolbars and small icon buttons fail it.
- Accessible Authentication bans the cognitive test. A login step must not require a memory test, a puzzle, or transcription unless an alternative exists. That rules out a lot of what teams currently ship as security theatre.
- One deadline moved and one did not. The US title II dates were extended by an interim final rule effective 20 April 2026. The European Accessibility Act date of 28 June 2025 has already passed, with a transitional provision to 28 June 2030 only for services that were lawfully in use before it.
Which Rules Actually Apply to You
Three regimes cover most products, and they are triggered by who your buyer is rather than by where your office is.
ADA title II covers US state and local government entities, which includes public school districts, public universities, transit agencies and city services. The technical standard is WCAG 2.1 Level AA for web content and mobile apps. The Department of Justice published an interim final rule effective 20 April 2026 that extended the original compliance dates. Entities with a total population of 50,000 or more moved from 24 April 2026 to 26 April 2027, and entities under 50,000 along with special district governments moved from 26 April 2027 to 26 April 2028. The Department explained that it had overestimated how available the technology to do this work would be. If you sell software to a district, this is your buyer requirement whether or not the law reaches you directly.
The European Accessibility Act has applied since 28 June 2025 across a broad set of consumer facing products and services, with technical requirements underpinned by the harmonised European standard EN 301 549. Service providers whose services were already lawfully in use before that date have a transitional period to 28 June 2030. If you sell into the EU, this is not a future problem.
Everything else is commercial pressure rather than statute, and it is increasingly effective. It applies to mobile apps and web apps alike, since the title II standard names both. Enterprise procurement questionnaires ask for conformance evidence, and not having it loses deals quietly, without anybody telling you that accessibility was the reason.
The three accessibility regimes, and what each one asks of a design team
| Regime | Who it binds | Technical standard | The date | What it means for design |
|---|---|---|---|---|
| ADA title II, USA | US state and local government entities, including school districts | WCAG 2.1 Level AA for web content and mobile apps | 26 April 2027 for population 50,000 plus, 26 April 2028 below that and for special districts | Conformance evidence becomes a procurement question, so build to 2.2 and cover it |
| European Accessibility Act | Providers of covered consumer facing products and services in the EU | Underpinned by harmonised standard EN 301 549 | Applied since 28 June 2025, transitional to 28 June 2030 for services already in use | Already in force, so treat it as a current obligation rather than a roadmap item |
| WCAG 2.2 itself | Nobody by law, everybody by standard | W3C Recommendation, 12 December 2024 | Current since December 2024 | Six new criteria at A and AA, led by target size and accessible authentication |
| Commercial pressure | Anyone selling to enterprise or public sector buyers | Whatever the buyer questionnaire names, usually WCAG AA | Now, and it is never announced | Deals are lost quietly, so keep conformance evidence current and ready to send |
Which should you choose
WCAG 2.2 status and criteria from the W3C Recommendation, target size figure from the W3C Understanding document for 2.5.8. Title II standard and extended dates from ada.gov and Federal Register 2026-07663. European Accessibility Act dates from European Commission material. Read 2026-08-27. Not legal advice.
What WCAG 2.2 Added, in Designer Terms
WCAG 2.2 became a W3C Recommendation on 12 December 2024. It adds nine success criteria and removes one, 4.1.1 Parsing, which had become obsolete. Six of the additions are at Level A or AA. Here is what each of those six actually means when you are drawing screens.
Focus Not Obscured, Minimum, Level AA. When a component receives keyboard focus it must not be entirely hidden by other content. In practice this is about sticky headers, floating action bars and cookie banners, which routinely sit on top of the element a keyboard user has just tabbed to. The user is on the control, and cannot see it.
Dragging Movements, Level AA. Anything achieved by dragging must also be achievable with a single pointer action that is not a drag, unless dragging is essential. Sliders, kanban boards, reorderable lists and map interactions all need an alternative, typically buttons or a menu that performs the same move.
Target Size, Minimum, Level AA. Pointer targets must be at least 24 by 24 CSS pixels. There are five exceptions worth knowing, since they are how real interfaces pass. Undersized targets are acceptable if a 24 pixel diameter circle centred on each one does not intersect another target or its circle, which makes spacing an alternative to size. There are further exceptions where an equivalent control elsewhere on the page meets the size, where the target is inline within a sentence, where the browser controls the rendering, and where the size is essential to the information being conveyed, such as pins on a map. This is the criterion most likely to force changes to an existing design system.
Accessible Authentication, Minimum, Level AA. No step in a login process may require a cognitive function test, such as remembering a password, solving a puzzle, or transcribing characters, unless there is an alternative or a mechanism to assist. Support for password managers, copy and paste into fields, and passkeys are the usual ways to satisfy it. Blocking paste in a password field, still common, now works against you.
Consistent Help, Level A. If you offer a help mechanism such as contact details, a chat widget or a help link, it must appear in the same relative place on every page that has it. Help that moves around is help that cannot be found.
Redundant Entry, Level A. Information the user already entered during a process must not be demanded again in the same process, unless re entering it is essential. Multi step checkouts and onboarding flows are where this fails.
The remaining three additions, Focus Not Obscured Enhanced, Focus Appearance and Accessible Authentication Enhanced, are Level AAA. Most teams should treat AA as the target and AAA as selective.
The Design Decisions Behind Most Failures
In practice a small number of decisions account for the overwhelming majority of problems we find, and every one of them is made in design rather than in code.
Contrast chosen for the mockup. Light grey text on white looks refined in a presentation and fails on a laptop screen in daylight. Contrast is a measurable ratio, so put it in the design tokens and check it there rather than arguing about it per screen.
Focus states designed away. Removing the focus ring because it is visually noisy makes the product unusable by keyboard. Design a focus state you are happy with instead of deleting the one you inherited, and check that tab order follows the visual order, which it stops doing as soon as layouts are reordered with CSS.
Colour carrying meaning alone. Red for error and green for success is fine as reinforcement and insufficient on its own. Pair it with an icon, a label, or text.
Forms that explain nothing. Placeholder text used instead of a label disappears exactly when the user needs it. Errors must say what is wrong and how to fix it, must be associated with the field programmatically, and must be announced rather than only shown in a colour change at the top of the page.
Content trapped in images. Text baked into an image cannot be resized, translated, read aloud, or selected. This includes the pricing table somebody exported as a PNG.
Motion with no way out. Parallax, autoplay and large transitions cause real problems for vestibular disorders. Respect the reduced motion preference the operating system already exposes.
Touch targets sized for a mouse. Dense icon rows designed on a large monitor become unusable on a phone, and now fail Target Size (Minimum) as well. This is the failure we see most often on mobile, and it is why we treat target sizing as part of mobile app design rather than a late accessibility fix.
Accessibility work is cheap in Figma and expensive in a remediation project. Contrast, focus, target size and error handling are decisions we make while drawing the component, and once they live in the design system every screen built from it inherits them. Teams that treat it as a pre launch audit are paying to rebuild interfaces they already shipped, usually under a procurement deadline.
Anurag Kurmi, Unico Connect
Where This Belongs in the Process
Not at the end. Retrofitting accessibility into a finished interface is close to redesigning it, because the failures are structural rather than cosmetic.
During design system work, bake the ratios and sizes into tokens and components. Contrast pairs, focus states, minimum target sizes and spacing rules belong there, so that conformance is inherited by default rather than achieved per screen.
During design review, check keyboard order, focus visibility, error copy and any interaction that currently only works by dragging.
During build, the questions are semantic structure, real headings, labelled controls and correct roles, which is mostly a matter of using the right element rather than reaching for a div.
During test, combine automated and manual, because automation is necessary and badly insufficient. Automated tooling reliably catches contrast, missing alternative text and missing labels, and it cannot tell you whether focus order makes sense or whether an error message is comprehensible. Tab through the whole flow with the mouse unplugged, then listen to it with a screen reader. Most problems surface within five minutes of doing that.
What It Costs
Designed in from the start, accessibility adds very little, because it is mostly a set of constraints applied while making decisions you were making anyway. Choosing a contrast ratio takes the same time as choosing a colour.
Retrofitted, it is a project. Component libraries change, layouts change, and every screen has to be retested. That is the version teams are usually quoting when they call accessibility expensive, and the expense is a consequence of the timing rather than of the requirement.
Two other returns are worth stating plainly. The design constraints improve the product for everyone, since clear labels, adequate contrast and generous targets are simply better interface design. And conformance evidence is now something enterprise and public sector buyers ask for directly, which makes it a commercial asset rather than a cost line. If you are already tracking design performance, treat conformance as one more measure alongside the others in our guide to measuring UI and UX success.
Where These Numbers Come From
The WCAG 2.2 publication date, the nine added success criteria with their levels, and the removal of 4.1.1 Parsing come from the W3C Recommendation at w3.org/TR/WCAG22. The 24 by 24 CSS pixel figure and its five exceptions come from the W3C Understanding document for Success Criterion 2.5.8. The ADA title II technical standard of WCAG 2.1 Level AA and the extended compliance dates come from the Department of Justice material on ada.gov and the interim final rule published in the Federal Register on 20 April 2026, document 2026-07663. The European Accessibility Act application date of 28 June 2025, the harmonised standard EN 301 549 and the transitional provision to 28 June 2030 come from European Commission material. All read on 27 August 2026. This article describes design practice and is not legal advice.
Frequently Asked Questions
Which version of WCAG should we design to in 2026?
WCAG 2.2 Level AA. It became a W3C Recommendation on 12 December 2024 and is a superset of WCAG 2.1 Level AA, which is the version named in the ADA title II rule. Designing to 2.2 satisfies the regulation and the current standard at once, which is why the version gap is not worth managing separately.
When do the ADA title II accessibility deadlines fall?
For public entities with a total population of 50,000 or more, 26 April 2027. For entities under 50,000 and special district governments, 26 April 2028. Those dates come from an interim final rule effective 20 April 2026 that extended the original deadlines of 24 April 2026 and 26 April 2027. The technical standard is WCAG 2.1 Level AA for web content and mobile apps.
What is the minimum touch target size under WCAG 2.2?
At least 24 by 24 CSS pixels, under Success Criterion 2.5.8 Target Size (Minimum) at Level AA. Five exceptions apply, the most useful being spacing, where a smaller target passes if a 24 pixel diameter circle centred on it does not intersect another target or its circle. Inline targets within sentences and browser rendered controls are also excepted.
What did WCAG 2.2 change compared with 2.1?
It added nine success criteria and removed one, 4.1.1 Parsing. Six of the additions are at Level A or AA, so they affect any team targeting AA. Those are Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum) and Accessible Authentication (Minimum) at AA, plus Consistent Help and Redundant Entry at A. The other three additions are AAA.
Does the European Accessibility Act apply to our app?
If you offer covered consumer facing products or services in the EU, very likely yes, and it has applied since 28 June 2025. Technical requirements are underpinned by the harmonised standard EN 301 549. There is a transitional provision to 28 June 2030, but only for services that were already lawfully in use before June 2025, so it is not available to anything new.
Can automated accessibility testing be trusted?
Only for part of the job. Automated tools reliably catch contrast failures, missing alternative text and missing form labels, which is genuinely useful. They cannot judge whether focus order is logical, whether an error message tells a user how to recover, or whether alternative text is meaningful rather than merely present. Combine automated checks with keyboard testing and a screen reader pass.
Is accessible design expensive?
Designed in from the start it costs very little, because it is a set of constraints on decisions you are already making. Retrofitted into a shipped product it is a substantial project, since component libraries and layouts have to change and every screen needs retesting. The expense people associate with accessibility is nearly always the cost of having left it until the end.
Who is responsible for accessibility, design or engineering?
Both, at different points. Contrast, focus states, target size, error copy and interaction alternatives are design decisions. Semantic structure, labelling and roles are engineering decisions. The failures that are most expensive to fix are the design ones, because they propagate through every screen built from the same components.
Conclusion
Accessible design is no longer a values conversation. It is a standard with a version number, a set of dates that have either passed or are approaching, and a buyer who will ask you for evidence. Design to WCAG 2.2 Level AA, put contrast, focus and target size into your design tokens rather than your launch checklist, and test with a keyboard before you test with a tool.
Do that and the compliance question answers itself, and the interface gets better for everybody in the process. For how we approach this in practice, see our UI and UX design services, our guide to measuring UI and UX success, or the education app development guide for a sector where accessibility conformance is a procurement gate. To talk through a specific product, contact us.
