Accessibility is UX: 10 quick fixes that help every user

Try reading your own website on your phone, outside, at noon. The light grey text you chose because it looked elegant almost disappears. The tiny close button on the pop-up takes three tries. For a few minutes you are using your site the way many people use it every day.

That is why I think of accessibility as plain good UX. It means making a site usable by people with disabilities, and the same fixes help someone in bright sun, on a slow phone, with a broken wrist or holding a baby in one arm. Microsoft's inclusive design team puts it as "solve for one, extend to many".

How big the gap is

The World Health Organization estimates that 1.3 billion people experience significant disability, which is 16% of the world's population, or 1 in 6 of us.

The web is not keeping up. Each year WebAIM runs automated checks on the home pages of the top one million websites. Its 2026 report, based on February 2026 data, found detectable failures on 95.9% of home pages, with an average of 56.1 errors per page. Automated tools only catch some problems, so the real picture is worse.

The good news is in the detail. The six most common failures were:

Every one of these is quick to fix.

A 30-second guide to WCAG 2.2

WCAG stands for Web Content Accessibility Guidelines, the standard published by the W3C, the body that sets web standards. WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the current edition is dated 12 December 2024. It is made of numbered "success criteria", each one a testable rule, at three levels: A (the minimum), AA (the level most laws and contracts ask for) and AAA (the strictest).

Below, each fix names the criterion it meets, so you can look it up or point a developer to it.

The 10 fixes

1. Make text contrast strong enough

WCAG 1.4.3 Contrast (Minimum), Level AA. Normal text needs a contrast ratio of at least 4.5:1 against its background. Large text, meaning at least 18 point, or 14 point bold, needs at least 3:1.

Contrast ratio compares how light two colours are, from 1:1 (identical) to 21:1 (black on white). Use any free contrast checker. Light grey on white is the usual offender, and it was the most common failure in the WebAIM data.

2. Describe every meaningful image

WCAG 1.1.1 Non-text Content, Level A. Images that carry information need a text alternative (the alt attribute) that serves the same purpose. Screen readers, software that reads a page aloud, use it.

Write what the image tells the reader, not what it looks like pixel by pixel. For a product photo: alt="Blue canvas tote bag with leather handles". For a purely decorative image, use an empty alt="" so screen readers skip it.

3. Label every form field, and explain errors in words

WCAG 3.3.2 Labels or Instructions, Level A and 3.3.1 Error Identification, Level A. Every input needs a visible label, connected in code, for example <label for="email">Email</label>. Placeholder text inside the box is not a label; it disappears as soon as people type.

When something goes wrong, say which field and what to do, in text: "Enter a date in the format DD/MM/YYYY." A red border alone is not enough.

4. Give every link and button a name

WCAG 2.4.4 Link Purpose (In Context), Level A and 4.1.2 Name, Role, Value, Level A. An "empty" link or button has no text a screen reader can announce, which is common with icon-only buttons. Add a text label, or aria-label="Search" on an icon button.

While you are there, replace "Click here" and "Read more" with links that make sense on their own: "Read the pricing guide".

5. Set the page language

WCAG 3.1.1 Language of Page, Level A. One attribute, <html lang="en">, tells screen readers and translation tools which language to use. Without it, a screen reader may read English text with the wrong pronunciation rules. It is the smallest fix on this list.

6. Make everything work with a keyboard, and show where focus is

WCAG 2.1.1 Keyboard, Level A, 2.4.7 Focus Visible, Level AA and, new in 2.2, 2.4.11 Focus Not Obscured (Minimum), Level AA. Some people cannot use a mouse and move through a page with the Tab key. Every link, button and form control must be reachable that way, and the focused item needs a visible outline.

The new 2.2 rule adds that the focused item must not be entirely hidden by something the site itself added, such as a sticky header or a cookie banner. Never remove the browser's focus outline without designing a clear replacement.

7. Make tap targets big enough

WCAG 2.5.8 Target Size (Minimum), Level AA, new in 2.2. Targets for pointer input should be at least 24 by 24 CSS pixels. Smaller targets pass only in specific cases: for example, when they are spaced so a 24-pixel circle centred on each does not overlap another target, or when they are links inside a sentence. This helps people with tremors, and everyone using a phone on a bus.

8. Do not use colour as the only signal

WCAG 1.4.1 Use of Color, Level A and 1.4.11 Non-text Contrast, Level AA. If a chart line, a required field or an error is shown only by colour, people with colour blindness may miss it. Add a label, icon, pattern or text. Separately, the parts of controls people need to see, like input borders and icons, need at least a 3:1 contrast ratio against what is next to them.

9. Let text zoom and reflow

WCAG 1.4.4 Resize Text, Level AA and 1.4.10 Reflow, Level AA. Text must be resizable up to 200% without losing content or function. Content must also work at a width of 320 CSS pixels without scrolling sideways (except for things like maps or data tables that need two dimensions). A responsive layout that does not lock font sizes covers most of this.

10. Let people paste passwords and use password managers

WCAG 3.3.8 Accessible Authentication (Minimum), Level AA, new in 2.2. A login step cannot rely on a "cognitive function test", such as remembering a password or solving a puzzle, unless there is an alternative or help. Allowing paste and supporting password managers counts as that help. So the fix is mostly to stop blocking them. People with memory or learning difficulties benefit, and so does anyone with a long, strong password.

A worked example: one sign-up form, before and after

Seven changes, most of them a line or two of code. The form now works better for everyone, including the person filling it in on their phone at noon.