Accessibility in UX Design: A Practical Guide for Businesses

Accessibility in UX design means building a site or app that people can use whatever their eyesight, hearing, motor control or attention span. For a business, it matters for plain reasons. More people can buy from you. Some markets now have legal requirements. And the fixes (clearer contrast, forms that explain themselves) tend to make the product easier for everyone.

The WHO estimates that about 1.3 billion people, roughly 1 in 6 of us, live with a significant disability. Add people squinting at a phone in sunlight or a parent holding a baby in one arm, and "users with access needs" stops being a niche. It's a big slice of your traffic on any given day.

Below: what the standard asks for, the fixes we'd prioritise, and how to check your own site without buying anything.

What is WCAG, in one paragraph?

WCAG (Web Content Accessibility Guidelines) is the standard most accessibility laws and contracts point to. It's published by the W3C, and the current version, WCAG 2.2, became a W3C Recommendation on 5 October 2023. It's made of testable "success criteria" sorted into three levels: A (the minimum), AA and AAA. Most organisations target AA, which includes everything in A. AAA is a stretch goal for specific content, and the W3C itself doesn't recommend requiring it across whole sites. WCAG 2.2 is backwards compatible, so a site that meets 2.2 also meets 2.1 and 2.0.

The fixes that matter most for accessibility in UX design

Not every success criterion carries equal weight for a typical business website. These are the ones that break most often, and the ones that lock people out of the parts that earn you money: finding information and handing it over. Treat this as a website accessibility checklist, roughly in order of how often it bites.

Colour contrast

What goes wrong: light grey text on white. A brand-coloured button whose white text is hard to make out.

The rule: WCAG 2.2 AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Large means roughly 24px regular or about 18.5px bold. Interface components and meaningful graphics (input borders, icons, focus rings, chart lines) need 3:1 against what's next to them.

Check it yourself: use any free contrast checker. Paste in your text colour and background colour, read the ratio. Do it for body text, buttons, links and form borders. Logos are exempt, so you don't have to redraw your brand mark.

Contrast is easy to get right at the design stage and annoying to retrofit, because it often means adjusting brand colours. (We measure every new colour pairing before using it, and it's why our design system advice for startups starts with tokens that already pass.)

Keyboard access and visible focus

What goes wrong: imagine filling in a checkout with only a keyboard. You press Tab and it lands on the "Pay" button but there's no outline, so you can't tell where you are. Or the custom date picker simply won't open without a mouse.

People who rely on a keyboard include screen reader users and people with tremors or limited hand movement. If they can't reach a control, it doesn't exist for them.

The rules: everything must work by keyboard (Level A). The focus indicator must be visible (AA). And new in 2.2, the focused item can't be completely hidden behind something you added, such as a sticky header or a chat widget (AA).

Check it yourself: put the mouse away. Press Tab through your home page and your main form. Can you always see where you are, in a sensible order? Can you close pop-ups with Escape and submit the form? If you get stuck, so do your customers.

Form labels and error messages

Forms are where accessibility problems cost you directly. A sign-up or enquiry form that a screen reader can't make sense of is a lost lead.

What goes wrong: fields with no visible label, just placeholder text that vanishes as you type. Errors shown only as a red border, with nothing in words to say which field is wrong or why.

The rules: every input needs a label or instructions (A). Errors must be identified in text and described (A). If you know how to fix the error, say so (AA).

Check it yourself: submit your form empty. Is each error written in words, next to the right field? Would "Enter a phone number with country code, for example +44 20 7946 0000" help more than "Invalid input"? It nearly always would. Our UX audit checklist goes deeper on forms.

Alt text

What goes wrong: images with no alternative text, so a screen reader reads out the file name. Or decorative swirls described in loving detail.

The rule: meaningful images need a text alternative that serves the same purpose (A). Decorative images should be hidden from assistive technology with an empty alt.

Good alt text describes what the image is for, not every pixel. A product photo might say "Navy wool overcoat, front view." An icon-only button needs a name like "Close menu".

Headings structure

Screen reader users often jump between headings to scan a page. If your "headings" are just big bold paragraphs, that shortcut is gone.

Check it yourself: use a free browser extension that lists a page's headings. You should see one H1, then H2s for main sections and H3s under them, reading like a sensible table of contents. Headings chosen for their font size rather than their meaning are a common culprit.

Touch target size

This one is new in WCAG 2.2 and it catches a lot of mobile designs. Success criterion 2.5.8 (AA) asks for pointer targets of at least 24 by 24 CSS pixels, or enough spacing that small targets don't crowd each other. There are exceptions, such as links inside a sentence.

What goes wrong: tiny "x" buttons on pop-ups, or a quantity stepper where the minus and plus sit almost on top of each other. Anyone with less precise hand control taps the wrong one.

24px is the minimum, not the target. For primary actions in mobile apps we design bigger. If you're planning a new app, raise it early with whoever builds it, in-house or a mobile app development partner: target size belongs in the design spec, not on the polish list.

Captions and transcripts

Prerecorded video with audio needs captions (A). That includes your product demo and the explainer on your pricing page. Auto-generated captions are a starting point. Read them through before publishing; they mangle product names.

Captions also help anyone watching with the sound off on a train or in an open-plan office. That's the "better for everyone" effect in its simplest form.

Motion and reduced motion

Parallax scrolling and elements that zoom or slide in as you scroll can cause dizziness or nausea for people with vestibular disorders.

The rules: anything that moves automatically for more than five seconds, like a carousel, needs a way to pause or stop it (A). Nothing should flash more than three times a second (A). Letting people turn off motion triggered by interaction is a AAA criterion, but it's cheap to do well.

How: operating systems have a "reduce motion" setting, and websites can read it through the prefers-reduced-motion media query. When it's on, swap slides and zooms for simple fades or no animation at all. Ask your developer whether your site respects it. Many don't.

Custom components vs native ones

This is the decision that most often makes or breaks accessible web design, and it's made early, usually without anyone noticing.

Native HTML elements (a real button, a real checkbox) come with keyboard support and screen reader announcements built in. A "button" built from a styled div has none of that until a developer adds it all by hand.

So why not always use native? Native form widgets look different in every browser and are hard to style to a brand. Fair enough. Our own rule is that custom controls are fine, but they have to be built to the W3C's ARIA Authoring Practices patterns: correct roles, keyboard behaviour that matches what users expect, visible focus and state announced to screen readers. A custom dropdown should open with Enter or Space and move between options with the arrow keys, just like the real thing.

What we push back on is the middle ground: a custom component that looks finished but was only ever tested with a mouse. If your team doesn't have time to build it properly, use the native element and style what you can. When we work on web development projects, this is one of the first things we review.

How to test accessibility in UX design (and why a scanner isn't enough)

Automated checkers are useful. They're fast, and they catch things like missing alt attributes and low contrast. But the W3C is blunt that tools "can not determine accessibility, they can only assist". A scanner can tell you an image has alt text; it can't tell you the alt text says "image". It can't tell you your checkout is impossible to finish by keyboard.

A sensible routine for a business site looks like this:

1. Run an automated check on your key templates: home, a product or service page, a blog post, your main form. Fix the obvious errors.
2. Do a keyboard-only pass of the journeys that matter, such as enquiring or checking out. Note every place you get lost or stuck.
3. Try a screen reader. VoiceOver is built into every Mac and iPhone. NVDA is free on Windows. Spend twenty minutes listening to your home page and filling in your form. You'll hear missing labels and vague link text ("read more") immediately.
4. Test with real people who use assistive technology, if you can. Nothing replaces watching someone who knows their tools hit a wall you didn't know was there.

Build these into your normal process, not a pre-launch scramble. We cover where they fit in our piece on the UX design process.

Can AI fix accessibility for me?

Partly. AI tools can draft alt text and captions quickly. They can't judge whether a flow makes sense to someone using a screen reader, and overlay widgets that promise one-line compliance don't fix the underlying code. We've written more on where AI genuinely helps in AI in UX design.

Is WCAG compliance legally required?

It depends on where you operate and who your customers are. We're designers, not lawyers, so treat this as orientation and ask a lawyer about your specific situation.

A few things are clear from official sources:

• European Union: the European Accessibility Act has applied since 28 June 2025. It covers a range of products and services, including online shops and banking services. Service providers with fewer than 10 employees and under €2 million in turnover are exempt.
• United States: the Department of Justice has consistently taken the position that the ADA's requirements for businesses open to the public apply to what they offer on the web, and businesses do get sued over inaccessible websites.

Many other countries have their own rules, and WCAG is the usual technical yardstick. Our practical view on WCAG 2.2 for business websites: if you sell to customers in Europe or the US, aim for AA. It's the clearest target, and it puts you in a defensible position while you get proper legal advice.

What WCAG level should a business website aim for?

AA. It's the level legal and procurement standards most often point to, and it's achievable for any site built with care. Meet A first, since those are the most severe barriers, then work through AA.

Where to start this week

If you do nothing else, do two things: tab through your main conversion journey with the keyboard, and check the contrast of your body text and buttons. Those two checks alone tend to reveal whether accessibility was considered when your site was built or left for later.

If you'd like a second pair of eyes, accessibility is part of every project our UI/UX design team takes on, from first wireframe to handover. And if you're planning something new, you can tell us about your project and we'll tell you honestly what it would take.