Accessibility doesn't restrict your design, it enhances it - and the ADA deadline has just moved.

Accessibility is not a constraint, it's a quality enhancer

There's a persistent myth in our profession: accessibility imposes aesthetic compromises. After twenty years in the business, I can confirm the opposite. Accessibility constraints force clearer decisions, more legible hierarchies and more robust interfaces. Accessible design is almost always better design - period.

The figures bear this out: around 15% of the world's population lives with some form of disability, and visual impairments alone - color blindness, low vision, light sensitivity - affect hundreds of millions of people. But 2026 brings a twist you need to be aware of before planning ahead: in the United States, the compliance deadline that many were expecting for April 2026 has just been pushed back. Not a good reason to relax, as we shall see - because in Europe, the obligation is already here.

What's mandatory in 2026 (and what isn't)

Let's sort it out, because confusion reigns. In Europe, the European Accessibility Act came into force on June 28, 2025: for a wide range of digital products and services, accessibility is no longer good practice, it's the law. In the United States, the ADA Title II rule adopted on April 24, 2024 imposes WCAG 2.1 AA on state and local government web content.

What about WCAG 3.0? Still under development. The March 2026 working draft describes 174 "outcomes", but a final recommendation is not expected before 2028 at the earliest. Practical conclusion: the legal bar remains WCAG 2.1 AA, we're preparing for WCAG 2.2, and we're keeping an eye on 3.0 without building on it.

WCAG 2.2: criteria that directly affect designers

WCAG 2.2, published in October 2023, adds several criteria that concern visual work. Focus Appearance imposes clearly visible focus indicators - contour of at least 2 pixels, 3

contrast with the environment. Target Size sets a touch target of at least 24 by 24 pixels, with a recommendation to 44 by 44 aligned with iOS and Android. Dragging Movements requires an alternative to any drag-and-drop action. Accessible Authentication prohibits cognitive tests such as CAPTCHA-puzzles without an alternative. Each of these additions improves the experience for everyone, not just people with disabilities.

Numerical thresholds to be systematically checked

These are the values I check at each iteration. They are non-negotiable.

Criterion	Threshold
Normal text (contrast)	4.5
Large text (18 pt, or 14 pt bold)	3
UI components and graphic indicators	3
Touch target (minimum / recommended)	24×24 px / 44×44 px
Body text	≥ 16 px
Line height	1.5× the size
Letter spacing	0.12em

These typographic values, derived from WCAG best practice, improve legibility for everyone without exception - not just the users targeted by the standard.

APCA: the future of contrast assessment

The current WCAG 2.x ratio model has known limitations: it ignores visual context, deals poorly with size granularity and does not faithfully reflect the eye's actual perception. The Advanced Perceptual Contrast Algorithm, developed by Andrew Somers as part of WCAG 3.0, proposes an approach based on perception: thin text requires more contrast than a large headline, and light on dark is not perceived as the opposite. In concrete terms, APCA allows for richer, more nuanced palettes, while guaranteeing real legibility superior to the current model - good news for designers who feel constrained by WCAG 2.x ratios. As WCAG 3.0 is still a long way off, I recommend familiarizing yourself with APCA now: the tools are starting to integrate it, and understanding contrast perception makes your chromatic decisions more solid, whatever the formal standard.

Beyond contrast: inclusive design

Visual accessibility isn't just about ratios. The most cost-effective principle: color must never be the sole vector of information. A field in error cannot be indicated by a simple red border - it needs an icon, a text, a pattern. A graphic can't distinguish its series by color alone - add patterns, shapes or direct labels. This reflex eliminates a whole category of problems, and in passing solves the case of color blindness. I systematically simulate protanopia, deuteranopia and tritanopia in Figma with Stark, which I also use as a real-time contrast checker; on the code side, DevTools and Lighthouse complete the audit of semantic structure, ARIA labels and keyboard navigation.

Then there's movement, which is often forgotten: the media query prefers-reduced-motion respects the preferences of animation-sensitive users, any decorative animation must be able to be deactivated, and auto-scrolling content must offer pause and stop. The golden rule of my entire workflow is to integrate these checks early on. If accessibility is treated as a final validation, it becomes a source of rework and frustration; if it is integrated into the design criteria from the outset, it naturally leads to better decisions with no discernible effort. The American deadline may have slipped by a year, but good accessible design has never waited for the law.