Accessibility in UI and UX Design for 2026
Anurag Kurmi
Senior Full Stack Engineer, Unico Connect
In this article
Accessibility is now a compliance question with real dates on it. In the United States it is a procurement requirement with a deadline attached, and 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.
Almost every article on this subject gets one detail wrong, and it will shape what your team builds. The US regulation mandates WCAG 2.1 Level AA, while the current W3C standard is WCAG 2.2, published as a Recommendation in October 2023, which adds nine success criteria that 2.1 does not contain. If you build strictly to the regulation, you ship against an older standard. Building to 2.2 satisfies both.
Below we set out which rules bind you, what the newer criteria require of designers, and the handful of design decisions behind most real failures.
Quick Answer
Design to WCAG 2.2 Level AA. It is the current W3C standard, first published as a Recommendation on 5 October 2023, and content that conforms to it also conforms to 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 with a total 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 ordinary ones, namely contrast, focus order, target size, error handling in forms, and content that only exists as an image.
Key Takeaways
- Set your target at WCAG 2.2 even though ADA title II names WCAG 2.1 Level AA. The current W3C Recommendation is 2.2, and W3C states that content conforming to 2.2 also conforms to 2.1, so one target covers the regulation and the standard.
- Six of the nine new criteria sit at A or AA, which makes them the new work for any team targeting 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.
- Under Target Size (Minimum), pointer targets must be at least 24 by 24 CSS pixels, with five defined exceptions. Dense toolbars and small icon buttons fail it, so this is the criterion most likely to force a change to an existing design system.
- Accessible Authentication says a login step must not require a memory test, a puzzle, or transcription unless an alternative or an assisting mechanism exists, though tests that only ask the user to recognise objects, or to identify non text content such as a photo they supplied, are allowed at AA. That rules out a lot of what teams currently ship as security theatre.
- Both US title II dates were extended by an interim final rule effective 20 April 2026, so recheck the date that applies to your buyers. The European Accessibility Act date of 28 June 2025 did not move and has already passed, with a transitional period to 28 June 2030 only for products that service providers were already lawfully using to provide similar services before 28 June 2025, and for service contracts agreed before then.
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. Until 28 June 2030, service providers may keep providing their services with products they were already lawfully using for similar services before 28 June 2025. Service contracts agreed before 28 June 2025 may run unchanged until they expire, but for no longer than five years from that date. If you sell into the EU, treat it as a current obligation.
Everything else is commercial pressure with no statute behind it, and it is increasingly effective. It applies to mobile apps and web apps alike, just as the title II standard covers 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 products already used to provide services | 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 since 5 October 2023, current edition 12 December 2024 | Current since October 2023 | 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, W3C and title II sources rechecked September 2026. Not legal advice.
What WCAG 2.2 Added, in Designer Terms
WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the current edition is dated 12 December 2024. It adds nine success criteria and removes one, 4.1.1 Parsing, which had become obsolete. W3C notes that teams required by policy to meet 2.1 may still need to test and report 4.1.1. Six of the additions are at Level A or AA, and below is what each of those six means when you draw 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, so 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. Tests that only ask the user to recognise objects, or to identify non text content such as a photo they provided to the website, are also allowed at this level. 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, because users cannot find help that moves around from page to page.
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
The overwhelming majority of problems we find trace back to a small number of decisions, 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. Put it in the design tokens and check it there, so nobody has to argue about it screen by 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 works as reinforcement but is insufficient on its own, so pair the colour 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. An error message has to say what is wrong and how to fix it. It also has to be associated with the field programmatically and announced, instead of only showing up as 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 people with vestibular disorders. The operating system already exposes a reduced motion preference, so respect it.
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
It belongs at every stage from the design system onward. 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 every screen inherits conformance by default. We cover fluid grids and breakpoints in a separate post.
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, but 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 comes from the timing.
Accessibility also pays back in two other ways. The design constraints improve the product for everyone, since clear labels, adequate contrast and generous targets make for better interface design. Conformance evidence is something enterprise and public sector buyers now ask for directly, which turns it into a commercial asset. If you already track design performance, add conformance as one more measure alongside those in our post on 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. 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, and the W3C and Department of Justice sources were rechecked in September 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 5 October 2023, and content that conforms to it also conforms to 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.
Should we wait for WCAG 3.0?
No. The question comes up in almost every design review, so the reasons are worth spelling out. WCAG 3 is still a Working Draft. W3C published a fresh one on 10 September 2026, calls it an incomplete draft that will change, and says it is inappropriate to cite as anything other than a work in progress. It also works on a different model, with core requirements, a single conformance level and reporting tiers below and above it, so moving to it later will take more than adding a few rules to your current checklist. Nothing in current law points at it. The ADA title II rule names WCAG 2.1 Level AA and the European Accessibility Act works through EN 301 549, which tracks the 2.x line. Design to 2.2 Level AA now. Work done against 2.2 carries forward, because the underlying user needs do not change, and you can follow progress through the W3C introduction to WCAG 3.
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 period to 28 June 2030, but it covers only products that service providers were already lawfully using to provide similar services before 28 June 2025, and service contracts agreed before then, 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, and that coverage is worth having. 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 now comes with a version number and a set of dates, some already passed and the rest approaching, and your buyers will ask you for evidence. Design to WCAG 2.2 Level AA and put contrast, focus and target size into your design tokens rather than your launch checklist. Test with a keyboard before you test with a tool.
Do that and the compliance question answers itself, while the interface gets better for everybody. Our UI and UX design services page shows how we approach this in practice, and our guide to measuring UI and UX success covers the wider set of design measures. The education app development guide looks at a sector where accessibility conformance is a procurement gate. To talk through a specific product, contact us.
