Accessibility in UX Design: What It Means and Why It Matters

Accessibility is one of those terms that UX designers encounter early in their careers and assume they understand. You need sufficient colour contrast. You need alt text on images. You need keyboard navigation. Tick, tick, tick.

But treating accessibility as a checklist misses what it actually is: a design discipline in its own right. It requires the same kind of systematic thinking you bring to usability or information architecture. And increasingly, it is also a legal requirement that many organisations are only now waking up to.

This post covers what accessibility means in a UX context, the standards and legislation you need to know, practical techniques you can apply to your work today, and the tools designers use to test it properly.

What accessibility means in UX

When we talk about accessibility in UX design, we are talking about designing so that people with disabilities can use your product. That sounds straightforward, but the range of disabilities it covers is broad:

• Visual impairments — from low vision and colour blindness to complete blindness (users who navigate with screen readers)
• Auditory impairments — users who are deaf or hard of hearing and rely on captions, transcripts, and visual cues rather than sound
• Motor impairments — users who cannot use a mouse and navigate by keyboard, switch control, or voice input; users with tremors or limited fine motor control
• Cognitive disabilities — users with dyslexia, ADHD, memory difficulties, or conditions that affect how they process language and structure

What makes this interesting from a UX perspective is that the same person might experience different accessibility needs depending on context. A broken arm is a temporary motor impairment. Bright sunlight on a phone screen is a situational visual impairment. Watching a video in a quiet office without headphones creates the same need for captions as permanent hearing loss. This is the insight that drives inclusive design: solve for the edges and you improve the experience for everyone.

The business and legal case

About 1 in 5 people in the UK has a disability, according to ONS figures. That is not a niche audience. Inaccessible products exclude a significant portion of potential users, which means lost customers, lost revenue, and reputational risk.

On the legal side: the European Accessibility Act (EAA) came into force in June 2025. It applies to a wide range of digital products and services across the EU, including e-commerce platforms, banking services, transport ticketing, and media players. Businesses selling into the EU need to meet its requirements. UK organisations operating under equivalent domestic legislation derived from the EAA face similar obligations.

The public sector has been subject to accessibility regulations in the UK since 2018 under the Public Sector Bodies Accessibility Regulations. The EAA extends comparable requirements into the private sector.

None of this means accessibility is primarily a legal exercise. Compliance-driven accessibility tends to produce the minimum viable effort. Properly accessible products are better products — for everyone.

WCAG 2.2 explained

The primary international standard for digital accessibility is the Web Content Accessibility Guidelines, known as WCAG, published by the W3C (World Wide Web Consortium). The current version is WCAG 2.2, published in October 2023.

The four principles: POUR

WCAG 2.2 is organised around four core principles. Everything in the standard flows from these:

Perceivable — Information and user interface components must be presentable to users in ways they can perceive. If you can only see it or only hear it, some users are excluded.

Operable — User interface components and navigation must be operable. If something only works with a mouse, keyboard-only users and assistive technology users are excluded.

Understandable — Information and the operation of the interface must be understandable. This covers language, error handling, consistency, and predictability.

Robust — Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This is primarily a technical concern but has design implications for how components are structured.

Conformance levels

WCAG has three conformance levels:

• Level A — the minimum. Addresses the most critical barriers.
• Level AA — the standard that most products target. Covers a wide range of disabilities without being impractical to achieve.
• Level AAA — the most demanding level. Not typically required as a blanket standard, but worth considering for specific components.

When someone says a product is "WCAG compliant," they almost always mean WCAG 2.2 Level AA.

What is new in WCAG 2.2

WCAG 2.2 added nine new success criteria. The ones most relevant to UX designers are:

Focus Appearance (2.4.11/2.4.12) — Focus indicators must meet minimum size and contrast requirements. Thin, low-contrast focus rings that were common in older designs no longer meet the standard.

Dragging Movements (2.5.7) — Any functionality that uses a dragging gesture must also be achievable by a single pointer (tap or click). This matters for sliders, kanban boards, and any drag-and-drop interaction.

Target Size Minimum (2.5.8) — Interactive targets must be at least 24x24 CSS pixels, with adequate spacing between adjacent targets. This addresses the problem of tightly packed small buttons on mobile.

Accessible Authentication (3.3.8/3.3.9) — Authentication processes must not rely solely on cognitive function tests (solving puzzles, identifying objects) unless there is an alternative. This affects CAPTCHA implementations and some multi-factor authentication flows.

Inclusive design vs accessible design

These terms are related but not identical, and the distinction matters.

Accessible design refers to meeting a specific technical and design standard — primarily WCAG — so that people with disabilities can use your product. It is a defined, measurable target.

Inclusive design is a broader design philosophy. The principle, articulated clearly by the Microsoft Inclusive Design team, is to design for people at the margins of ability and context, because solutions that work for those users tend to work better for everyone. The classic example is kerb cuts: originally designed for wheelchair users, they are now used by parents with pushchairs, delivery workers with trolleys, and cyclists. Designing for the edge case improved the experience at the centre.

The two overlap significantly. Following WCAG will make your product more inclusive. Thinking inclusively will often lead you to accessibility solutions you would not have found by running a checklist. But a product can be technically WCAG-compliant and still be awkward or excluding for many users. Inclusive design asks the broader question: who are we not designing for, and what would it take to include them?

Practical accessibility techniques

Here is where accessibility meets the daily work of a UX designer. These are not abstract principles — they are decisions you make in Figma, in your component library, and in your design specifications.

Colour contrast

Normal body text requires a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold and above) requires 3:1. Non-text elements like icons and form borders require 3:1.

This is not just a visual nicety. It directly affects readability for users with low vision, colour blindness, or who are using a screen in bright sunlight.

Do not use colour alone to convey information

If your form validation uses red for errors and green for success, users who are colour-blind cannot distinguish them. Add an icon, a text label, or a pattern. This principle extends to charts, maps, and any interface element where colour carries meaning.

Keyboard navigation

Every interactive element in your product must be reachable and operable using only a keyboard. Tab moves between focusable elements; Enter or Space activates them; Escape closes modals and dropdowns. If you have built a custom dropdown, accordion, or date picker, it needs to follow the expected keyboard interaction patterns.

This is not just about keyboard-only users. Screen reader users navigate primarily by keyboard. Voice control users issue commands based on visible labels. A keyboard-navigable interface is the foundation for all of these.

Visible focus states

When a user navigates by keyboard, they need to see where the focus is at all times. Many designs suppress the browser default focus ring because it looks untidy, without providing an alternative. WCAG 2.2 Focus Appearance (Level AA) now requires that focus indicators meet minimum size and contrast requirements. Design explicit, on-brand focus states rather than removing them.

Alt text for images

Every image that conveys information needs a text alternative that describes its content. Purely decorative images should have an empty alt attribute (alt="") so screen readers skip them. The goal is that a screen reader user gets the same information from the alt text as a sighted user gets from the image.

Font sizes

WCAG does not specify a minimum font size, but 16px for body text is a widely accepted practical baseline. Smaller text forces users with low vision to zoom, which can break layouts that have not been designed responsively. Set your base size in relative units (rem, em) rather than fixed pixels so that users who have increased their browser default font size still get a proportionally larger result.

Form labels

Never use placeholder text as a form label. Placeholder text disappears when the user starts typing, leaving them with no way to check what the field is asking for. Every input needs a persistent visible label. Labels should describe what the field expects, not just its name.

Error messages

When something goes wrong in a form, the error message needs to be specific and actionable. "Error" or "Invalid input" is useless. "Your email address must include an @ symbol" tells the user what to fix. This connects to the error prevention heuristic discussed in heuristic evaluation — the best error message is one the user never needs to see, but when they do need it, it should actually help.

Heading hierarchy

Screen reader users often navigate a page by jumping between headings. If your headings are styled for visual hierarchy without following semantic order (H1, H2, H3), screen reader users get a confusing structure. One H1 per page. Headings nest logically. Do not skip levels.

Accessibility testing tools

You do not need to audit every design manually from scratch. These tools cover most of the common ground:

Colour Contrast Analyser (free, TPGi) — A desktop application that lets you pick any two colours on screen and see their contrast ratio. Essential for checking designs in real time.

WAVE (browser extension, free) — Overlays your live webpage with visual indicators of accessibility issues. Good for a quick audit of an existing product.

axe DevTools (browser extension, free tier) — Developer-focused accessibility testing tool. The free version catches a significant proportion of WCAG issues automatically.

VoiceOver (built into Mac and iOS) — Apple's screen reader. Free, widely used, and the best way to understand how a screen reader user actually experiences your product. Press Command + F5 on Mac to activate.

NVDA (free, Windows) — NonVisual Desktop Access, the most widely used screen reader on Windows. Used by many assistive technology users in the real world.

Stark (Figma plugin) — Checks colour contrast, simulates colour blindness, and helps you generate accessible design documentation.

A11y Annotation Kit (Figma, free) — A set of annotation components for marking up accessibility requirements on designs before handoff to developers.

How to get started

If you are working on an existing product, start with an audit. Run WAVE on your key pages. Check your colour contrast with the Colour Contrast Analyser. Tab through your most important user journey and see what happens. The issues you find will almost certainly cluster around the same recurring problems: low contrast text, missing focus states, unlabelled form fields, images without alt text.

Prioritise by impact. Fix the issues that affect the most users across the most important journeys first. An inaccessible checkout flow is more urgent than an inaccessible blog sidebar.

If you are starting a new project, build accessibility into your design process from the beginning. Include it in your design system documentation. Make contrast checking part of your colour selection process. Write alt text requirements into your content guidelines. Add keyboard navigation to your interaction specifications. Retrofitting accessibility into a finished product is expensive and frustrating. Building it in from the start is just design.

Want to build real accessibility skills?

Understanding WCAG 2.2 is one thing. Knowing how to apply it across a real product — how to run an accessibility audit, how to annotate designs for developers, how to use assistive technology to test your own work — is a different level of competence.

The Accessibility for UX course at UX Academy covers WCAG 2.2, the European Accessibility Act, inclusive design methods, and hands-on testing across a six-week live programme. You will work on real accessibility challenges with expert instructors and leave with a portfolio piece that demonstrates your skills to employers.

View the Accessibility for UX course