To make a website accessible, follow WCAG 2.2 at level AA: give text enough colour contrast, add meaningful alt text to images, label every form field, make everything work with a keyboard, keep focus visible, use proper headings and HTML elements, caption videos, and make buttons and links large enough to tap. Then test with automated tools and by hand.
The rest of this guide explains what WCAG is, what changed in version 2.2, the most common failures and how to fix them, with code, and how to test your site.
Key takeaways
- Aim for WCAG 2.2 level AA, which UK public sector sites must meet and which is the usual benchmark for private businesses in the UK, US and EU.
- Normal text needs a contrast ratio of at least 4.5:1, while large text, icons and focus indicators need 3:1.
- Label every form field, give images meaningful alt text and make everything work with a keyboard and visible focus.
- Automated tools find only a portion of problems, so add keyboard, zoom and screen reader testing.
What is WCAG?
The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility, published by the W3C. They are organised around four principles, often shortened to POUR:
- Perceivable: people can see or hear the content, or get an alternative (alt text, captions).
- Operable: people can use the interface with a keyboard, voice or switch device, and have enough time.
- Understandable: content and behaviour are predictable and clear.
- Robust: content works with browsers and assistive technologies such as screen readers.
Each guideline has testable success criteria at three levels: A (minimum), AA (the usual target, and the level UK public sector sites must meet) and AAA (enhanced, not expected across whole sites).
What changed in WCAG 2.2?
WCAG 2.2 became a W3C Recommendation on 5 October 2023. It added nine success criteria and removed one (4.1.1 Parsing, now obsolete because browsers handle markup errors consistently).
| Criterion | Level | In plain English |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky headers, cookie banners and chat widgets must not completely hide the focused element |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | No part of the focused element is hidden |
| 2.4.13 Focus Appearance | AAA | Focus indicators are large and high-contrast |
| 2.5.7 Dragging Movements | AA | Anything done by dragging can also be done with simple clicks or taps |
| 2.5.8 Target Size (Minimum) | AA | Click and tap targets are at least 24 by 24 CSS pixels, or have enough spacing |
| 3.2.6 Consistent Help | A | Help options, such as contact details or chat, appear in the same place on each page |
| 3.3.7 Redundant Entry | A | Do not make users re-enter information they already gave in the same process |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logins do not rely on memory or puzzle tests; allow password managers and pasting |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | Stricter version of the above |
Everything from WCAG 2.1 still applies, so 2.2 AA is 2.1 AA plus the new A and AA criteria.
What are the most common accessibility failures?
WebAIM's 2026 analysis of the top one million home pages found detectable WCAG failures on 95.9% of them, averaging 56 errors per page. The six most common problems were:
- Low-contrast text (83.9% of pages)
- Missing image alt text (53.1%)
- Missing form input labels (51%)
- Empty links (46.3%)
- Empty buttons (30.6%)
- Missing document language (13.5%)
These are all fixable without a redesign. Start here.
How do I fix the most common problems?
1. Colour contrast
Normal text needs a contrast ratio of at least 4.5:1 against its background. Large text (roughly 24px regular or 18.66px bold and above) needs 3:1. Icons, form field borders and focus indicators need 3:1 against neighbouring colours. Pale grey text on white is the classic failure. If you're choosing new brand colours, our colour palette generator shows contrast ratios and a colour-blindness preview as you go.
2. Alt text
Describe what an image communicates, not what it looks like in detail. Decorative images should have an empty alt attribute so screen readers skip them.
<img src="team.jpg" alt="Our four engineers outside the Leeds workshop">
<img src="divider.svg" alt="">
3. Form labels
Every input needs a programmatically linked label. Placeholder text is not a label: it disappears when you type and often fails contrast.
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">
4. Links and buttons with names
Icon-only buttons need an accessible name, and links should make sense out of context. "Click here" repeated ten times is meaningless to a screen reader user scanning a list of links.
<button type="button" aria-label="Open menu">
<svg aria-hidden="true" focusable="false"><!-- icon --></svg>
</button>
5. Page language
One attribute tells screen readers how to pronounce your content:
<html lang="en-GB">
6. Keyboard access and visible focus
Press Tab through your page. You should be able to reach every link, button and form control in a logical order, see where you are at all times, and operate menus and pop-ups with Enter, Space and Escape. Never remove focus outlines without replacing them:
:focus-visible {
outline: 3px solid #1d4ed8;
outline-offset: 2px;
}
7. Headings and structure
Use one <h1> per page and nest <h2> and <h3> logically. Use real <button>, <nav>, <main> and <ul> elements rather than styled <div>s; they come with built-in keyboard and screen reader support.
8. Target size
Make buttons and links at least 24 by 24 CSS pixels, or space them so a 24-pixel circle around each does not overlap its neighbour. Links inside sentences are exempt.
9. Video and audio
Pre-recorded video needs captions, and audio-only content needs a transcript. Avoid autoplaying media, or provide an obvious pause control.
How do I test my website for accessibility?
Use three layers:
- Automated checks. Tools such as Lighthouse, axe and the MakeItFlow accessibility check catch issues like missing alt text, contrast failures and missing labels quickly. They cannot judge whether alt text is meaningful or whether a journey makes sense, so they only find a portion of problems.
- Manual checks. Keyboard-only navigation, zooming the page to 200% and 400%, turning off images, and checking the page at a 320-pixel width without horizontal scrolling.
- Assistive technology. Try a screen reader: NVDA on Windows is free, and VoiceOver is built into Macs and iPhones. Ideally, test key journeys with disabled users.
Fixing accessibility often improves SEO and usability too. Proper headings, descriptive links and alt text help search engines as well as people; our SEO audit checklist covers the overlap.
Frequently asked questions
Is WCAG 2.2 a legal requirement in the UK?
For public sector websites, yes: they must meet WCAG 2.2 AA under the 2018 accessibility regulations. Private businesses have duties under the Equality Act 2010, for which WCAG 2.2 AA is the usual benchmark. See our UK accessibility checklist for detail.
What about the US and the EU?
In the US, the ADA covers businesses open to the public, and the Department of Justice's web guidance says that includes their websites. It hasn't set a technical standard for private businesses, so WCAG AA is the usual benchmark. State and local government sites must meet WCAG 2.1 AA under a 2024 DOJ rule, with compliance dates that an April 2026 interim final rule moved to April 2027 or April 2028, depending on population size. In the EU, the European Accessibility Act has applied since 28 June 2025 to many consumer services, including e-commerce, with an exemption for microenterprises providing services.
Do accessibility overlay widgets make a site compliant?
No. Overlays cannot fix underlying problems such as missing labels or broken keyboard navigation, and they can interfere with users' own assistive technology. Fix the code instead.
What about WCAG 3?
WCAG 3 is still a working draft with a different structure and scoring model. It is not a finished standard, so WCAG 2.2 remains the one to follow.
How long does it take to make a site accessible?
Fixing contrast, alt text, labels and language can take days. Complex components such as custom menus, carousels or checkouts take longer. Prioritise the journeys that matter most, like contact forms and checkout.
Does accessibility affect Google rankings?
There is no direct "accessibility" ranking factor, but many accessibility fixes, such as descriptive headings, alt text and fast, stable pages, overlap with good SEO and page experience.
What to do next
Start by finding the quick wins. MakeItFlow runs automated accessibility checks using Lighthouse as part of a free website audit, flagging contrast, alt text, labels and language issues. It is not a compliance certificate, so follow up with keyboard and screen reader testing. If layout shifts make your pages hard to use, read our guide to fixing cumulative layout shift.
Related reading
- PX vs REM vs EM: Which CSS Unit Should You Use?: PX vs REM vs EM explained: how each CSS unit is calculated, why rem respects users' font settings, when px is still right, and a quick conversion table.
Sources
More guides for your industry
Free checklist (PDF)
Free schools & training website checklist
29 practical checks for schools & training: website speed and mobile, Google Business Profile and reviews, email security, booking and enquiry handling, and AI search visibility. Each one says why it matters, and many link to a free tool that checks it.
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 30 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
