How to Design for Accessibility in 2026

Most products are designed for a specific kind of user: someone with normal vision, full motor control, no cognitive differences, using a mouse on a desktop or a finger on a touchscreen. Everything works for that user. For anyone else, the experience ranges from slightly inconvenient to completely unusable.

Approximately 1.3 billion people worldwide — including 26% of adults in the US — live with some form of disability. Visual impairments, motor limitations, cognitive differences, hearing loss: each category represents a large group of real people who will encounter your product and form a judgement about whether it works for them.

The business case for accessibility is not purely ethical, though the ethical case is clear. In 2025, there were over 5,000 web accessibility lawsuits in the US alone — a 27% year-on-year increase. 94.8% of websites still fail basic WCAG compliance checks. The gap between how common these legal actions are and how rarely teams build with accessibility in mind is enormous.

More practically: accessibility improvements benefit everyone. Clear navigation, adequate contrast, predictable structure, well-labelled form fields — these are better design for all users, not special accommodations for a subset. The product you build for your most constrained user tends to be the most usable product for everyone.

What WCAG Is and What You Need to Know About Version 2.2

WCAG stands for Web Content Accessibility Guidelines. Maintained by the W3C, it is the international standard that defines what "accessible" means for digital products. Legal frameworks around the world — including the Americans with Disabilities Act (ADA) in the US, the Equality Act in the UK, and similar legislation in India and the EU — reference WCAG as the benchmark for compliance.

WCAG organises accessibility requirements into four principles, expressed as the acronym POUR:

• Perceivable — Information must be presentable to users in ways they can perceive. Content that only exists as colour or sound, with no alternative, fails this principle.
• Operable — UI components and navigation must be operable. A user who cannot use a mouse must be able to operate everything with a keyboard.
• Understandable — Content and operation must be understandable. Error messages must explain what went wrong. Form fields must have labels. Navigation must be predictable.
• Robust — Content must be robust enough to be interpreted by a wide variety of assistive technologies, including screen readers and alternative input devices.

Each success criterion falls under one of three conformance levels — A (minimum), AA (standard target for most organisations), and AAA (enhanced). WCAG 2.2 AA is the current legally relevant target.

What WCAG 2.2 Added

WCAG 2.2, the current recommendation, introduced nine new success criteria over 2.1. The most practically important for product teams:

Target Size (2.5.8 — Level AA): Interactive elements must be at least 24×24 CSS pixels. This addresses the common mobile design problem of touch targets that are too small — links and icons crammed together so tightly that users with larger fingers or limited motor control regularly tap the wrong one.

Focus Not Obscured (2.4.11 — Level AA): When a user navigates by keyboard, the focused element must not be completely hidden by other UI elements — sticky headers, cookie banners, fixed footers. A focus indicator that disappears behind a sticky nav bar means a keyboard user loses track of where they are.

Accessible Authentication (3.3.8 — Level AA): Authentication must not require users to solve cognitive puzzles (CAPTCHAs that require reading distorted text, for example) without providing an accessible alternative. Password managers must be allowed to auto-fill. SMS OTPs must be copy-pasteable.

Redundant Entry (3.3.7 — Level A): If a user has already entered information in a process (say, their address on step 2 of a checkout), they should not be required to re-enter the same information on step 4. This benefits users with cognitive or memory disabilities, and it benefits everyone else who finds re-entry tedious.

The Four Areas That Cause Most Accessibility Failures

1. Colour Contrast

The most common accessibility failure on most websites. WCAG requires a contrast ratio of at least 4.5:1 between text and its background for normal-size text, and 3:1 for large text (18pt or 14pt bold). UI components — buttons, input borders, icons — also need 3:1 contrast against adjacent colours.

In practice, this catches light grey text on white backgrounds, pale blue links on light backgrounds, placeholder text that's almost the same colour as the input background, and disabled button states that are invisible to users with low vision.

Testing contrast is simple: Figma has contrast ratio checking built in. Browser tools like the Chrome DevTools accessibility panel and dedicated tools like WebAIM's Contrast Checker produce an instant pass/fail. There is no design reason to ship insufficient contrast — the fix is adjusting a colour value.

A critical nuance: colour alone must not be the only way information is conveyed. An error state that turns a form field red with no other indicator — no error message, no icon — is inaccessible to colour-blind users. Pair colour changes with text, icons, or patterns.

2. Keyboard Navigation and Focus States

Every interactive element in your product — every link, button, form field, dropdown, modal trigger — must be reachable and operable using only a keyboard. Tab navigates forward through interactive elements. Shift+Tab navigates backward. Enter or Space activates buttons. Arrow keys navigate within menus and select components.

The focus indicator — the visual outline that shows which element is currently focused — must be visible. This is the single most commonly broken accessibility feature in modern web design. Designers routinely remove the default browser focus outline (outline: none) because it looks inelegant without replacing it with a custom alternative. The result is a keyboard user with no visual feedback about where they are on the page.

WCAG 2.2 strengthens focus requirements: focus indicators must not be obscured by other elements, and they must meet minimum size and contrast requirements. In practice, design a focus style that is clearly visible — a 2px solid outline in a high-contrast colour, or an offset ring that works against both light and dark backgrounds — and apply it as a standard component state in your design system.

Keyboard navigation also requires logical tab order (matching the visual reading order), no keyboard traps (the user must be able to exit every component, including modals and dropdowns), and skip navigation links (allowing keyboard users to jump past repetitive navigation directly to the main content).

3. Screen Reader Compatibility

Screen readers — VoiceOver on macOS/iOS, TalkBack on Android, NVDA and JAWS on Windows — convert digital interfaces into audio narration. A user listening to a screen reader needs the same information that a sighted user gets visually, expressed through the document structure.

The foundation is semantic HTML. Using <header>, <nav>, <main>, <section>, <footer>, and heading tags (<h1> through <h6>) in correct hierarchy gives screen readers the structure they need to navigate efficiently. A page built entirely out of <div> tags with CSS positioning conveys no structure to a screen reader.

Every meaningful image needs alt text that describes what it conveys — not "image" or the filename, but what a sighted user would understand from seeing it. Decorative images (visual flourishes with no informational value) get alt="" so screen readers skip them.

Form fields need associated <label> elements. Not placeholder text — placeholder text disappears when the user starts typing, and many screen readers don't announce it reliably. A label associated with its input via the for/id attribute pair ensures the screen reader announces "Email address, edit text" when the user focuses the field.

Custom interactive components — carousels, accordions, tabs, modals — need ARIA (Accessible Rich Internet Applications) attributes to communicate their role and state to assistive technologies. A <div> styled as a button needs role="button", tabindex="0", and keyboard event handlers. A modal needs role="dialog", aria-modal="true", aria-labelledby pointing to its title, and focus management that traps keyboard focus inside the modal while it's open.

4. Cognitive Accessibility

Cognitive accessibility is the most frequently overlooked category. It covers users with cognitive differences — dyslexia, ADHD, memory limitations, anxiety — and the design decisions that help them succeed.

Plain language: error messages that say "Email address format is invalid" are more helpful than "400 Bad Request." Instructions that explain what to do rather than what not to do. Headings that describe content rather than being clever.

Predictable patterns: navigation that is in the same location on every page, interactive elements that behave consistently, processes that explain what step the user is on and how many remain.

Adequate time: forms that expire sessions without warning create barriers for users who take longer to process information. If session timeouts are necessary, a warning with an option to extend removes the barrier.

Reduced cognitive load: one primary action per screen, clear visual hierarchy that guides the eye, error messages that appear adjacent to the field they describe rather than at the top of the page in a list.

The Accessibility Audit Checklist

A practical baseline to run against any product before shipping:

How to Test Accessibility Without an Expert Audit

Automated tools catch roughly 30–40% of issues — they're a starting point, not a complete picture. Run these first:

• Lighthouse (Chrome DevTools → Lighthouse → Accessibility): built-in, fast, highlights common violations
• axe DevTools (browser extension): more detailed than Lighthouse, with specific WCAG criterion references
• WAVE (WebAIM browser extension): good for visual annotation of issues directly on the page

Manual tests for what automation misses:

• Unplug your mouse and attempt to complete each core user flow with only a keyboard. Note every point where you get stuck.
• Enable VoiceOver (macOS: Cmd+F5) or NVDA (Windows, free download) and navigate through each page. Note anything that isn't announced clearly.
• Zoom your browser to 200% and check that no content is cut off, overlapping, or becomes inaccessible.
• Use a tool like the Colour Blindness Simulator (Figma plugin or browser extension) to view your UI as a colour-blind user would.

Testing with real users who use assistive technology is the most valuable signal you can get, but it's a step that comes after the automated and manual baseline.

FAQ

Does accessibility apply to mobile apps or just websites? Both. Accessibility standards for native mobile apps are defined by platform guidelines — Apple's Human Interface Guidelines for iOS and Google's Material Design accessibility guidelines for Android — alongside WCAG's mobile guidance. The principles are the same: sufficient contrast, touch targets that are large enough, screen reader support (VoiceOver on iOS, TalkBack on Android), and keyboard/switch access support. Apps distributed on the App Store and Play Store can face accessibility-related complaints regardless of their web presence.

If I use a component library like shadcn/ui or Radix UI, am I automatically accessible? Largely, yes — for the components the library provides. Radix UI in particular is built with accessibility as a first principle: all interactive components handle keyboard navigation, ARIA attributes, and focus management correctly. The gaps are in how you use them: the colour choices you apply, the content you put in them, and any custom components you build outside the library. Using an accessible component library is a strong foundation, not a complete solution.

What is the legal risk of not meeting WCAG 2.2 AA in India? India's Rights of Persons with Disabilities Act (RPWD Act) 2016 and the associated Guidelines for Indian Government Websites reference accessibility standards. For private sector companies, the risk is lower in India than in the US (where ADA litigation is common) or the EU (where the European Accessibility Act has broad reach). However, for products with US, UK, or EU user bases, legal exposure is real and growing. The safer approach is building to WCAG 2.2 AA regardless of primary market, as it costs little at design time and significantly more to retrofit.

How do I handle accessibility in dark mode? Dark mode requires its own contrast audit. A colour scheme that passes 4.5:1 on a white background may fail on a dark background because the contrast relationships are inverted. For every text and UI colour in your light theme, verify the equivalent dark theme colour passes the same contrast requirements. Design systems that use semantic tokens make this manageable — the light mode token text-primary maps to a dark value and the dark mode token maps to a light value, and contrast is verified for both.

Should accessibility be done by designers or developers? Both, at different stages. Designers are responsible for specifying accessible colour choices, interaction patterns, focus states, and component structures. Developers are responsible for implementing semantically correct HTML, ARIA attributes, keyboard handling, and ensuring the design is implemented as specified. Accessibility that's designed correctly but implemented with non-semantic markup still fails. It's a shared responsibility across the team, which is why accessible component libraries and design system token layers are so valuable — they encode the decisions so neither team has to rediscover them.

If your product hasn't had an accessibility review, the probability that it has significant failures is very high — 94.8% of websites do. An audit identifies the specific issues, prioritises them by impact, and gives your team a concrete remediation plan. Request an accessibility audit and we'll give you a clear picture of where you stand and what it takes to get to WCAG 2.2 AA compliance.

UI/UX Design services · Why good design is good business · What is a design system

Author: Abdul Rahaman
Last updated: August 2026