Accessibility Fixes: Every WCAG Finding, One Place
An accessible website is one that people can use whatever their abilities: with a screen reader, with a keyboard instead of a mouse, with low vision, colour blindness or a tremor, or simply on a small screen in bright sunlight. The Web Content Accessibility Guidelines, WCAG, set out how to do that in testable rules.
The Accessibility Audit tests pages against WCAG 2.2 at level AA. This page explains what each finding means, which to fix first, and which of our guides fixes it.
Why accessibility matters, and what the law says
Around one in four adults in the UK has a disability, and many more have temporary or situational difficulties: a broken arm, an old monitor, a noisy train. A site that is hard to use for them loses visitors, sales and enquiries, usually without anyone noticing.
The legal position depends on who you are:
- UK public sector. The Public Sector Bodies Accessibility Regulations 2018 require websites to meet WCAG 2.2 level AA and to publish an accessibility statement.
- UK businesses and charities. The Equality Act 2010 requires service providers, including websites, to make reasonable adjustments so disabled people are not put at a substantial disadvantage. It does not name WCAG, but WCAG AA is the standard courts and advisers usually point to.
- Selling into the EU. The European Accessibility Act has applied since 28 June 2025 to many consumer services, including online shops, with some exemptions for very small businesses. It is measured against the European standard EN 301 549, which is based on WCAG.
Accessibility also overlaps heavily with good SEO and with AI agents. Descriptive alt text, a clear heading structure, real links and labelled forms help search engines, AI assistants and automated agents understand and use a page, as well as people.
What an automated checker can and cannot find
Automated checking is fast and catches many common problems, but it cannot judge everything. A checker can tell that an image has no alt text; it cannot tell whether the alt text that is there actually describes the image. It can measure the contrast of text; it cannot always see text drawn inside an image.
| Automated checks catch well | Needs a person to check |
|---|---|
| Text with too little contrast against its background | Whether alt text is accurate and useful |
| Images, buttons and fields with no accessible name | Whether the reading and focus order make sense |
| Missing page language and page title | Whether keyboard users can reach and leave every control |
| Headings used out of order | Whether headings actually describe their sections |
| Invalid or conflicting ARIA attributes | Whether error messages are clear and helpful |
| Links with no text or duplicate vague text | Whether video has accurate captions |
Treat the checker as the first pass. Then spend ten minutes using the page with only a keyboard, and ten minutes with a screen reader such as NVDA on Windows or VoiceOver on a Mac or iPhone. Those two tests find most of what automation misses.
The fix guides
Each guide covers one kind of finding from start to finish: the WCAG success criterion behind it, what the checker found, how to fix it, how to test the fix and the questions people ask most.
Seeing the page
Fixing colour contrast covers
WCAG 1.4.3: a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, how to measure
it, and how to adjust brand colours without losing the brand. Fixing
alt text covers WCAG 1.1.1: what to write for informative images, why decorative images need an empty
alt="" rather than none, and how to fix many images at once.
Using the page without a mouse
Fixing keyboard navigation covers WCAG 2.1.1 and 2.1.2: reaching every control with Tab, operating it with Enter or Space, and never getting trapped in a menu or pop-up. Fixing focus indicators covers WCAG 2.4.7 and the new 2.4.11 in WCAG 2.2: a visible focus outline that is not hidden behind sticky headers or cookie banners.
Understanding the page
Fixing form labels covers WCAG 1.3.1 and 3.3.2: every field needs a label connected to it in the code, because placeholder text disappears and is not a label. Fixing heading structure covers using headings to mark real sections, in a logical order, so screen reader users can jump through the page. Fixing ARIA labels covers icon buttons with no name, ARIA that overrides visible text, and hidden elements that can still receive focus. Fixing vague link text covers WCAG 2.4.4: why "click here" and "read more" fail when links are read out of context.
By platform
The platform guides cover where the problems usually come from and how to fix them at source: WordPress, including themes and page builders; Shopify, including themes and apps that add pop-ups and widgets; and React and Next.js, including focus management and announcing page changes in single-page apps.
What changed in WCAG 2.2
WCAG 2.2 became a W3C Recommendation in October 2023 and is now the version most organisations work to. It keeps almost everything in WCAG 2.1 and adds new success criteria. The ones at levels A and AA that most often affect ordinary websites are:
| Criterion | Level | What it asks for |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | A focused control is not completely hidden by sticky headers, footers or banners. |
| 2.5.7 Dragging Movements | AA | Anything done by dragging, such as a slider, can also be done with single clicks or taps. |
| 2.5.8 Target Size (Minimum) | AA | Clickable targets are at least 24 by 24 CSS pixels, or have enough space around them. |
| 3.2.6 Consistent Help | A | Help such as a contact link or chat appears in the same place on each page. |
| 3.3.7 Redundant Entry | A | People are not asked to type the same information twice in one process. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logging in does not depend on memory or puzzle tests, and password managers and pasting work. |
WCAG 2.2 also removed 4.1.1 Parsing, because modern browsers and assistive technology handle the HTML errors it covered. Invalid HTML is still worth fixing, but it is no longer a WCAG failure on its own.
Which findings to fix first
- Anything that blocks a task completely. A keyboard trap, a form field with no label, or a button with no name can stop someone buying, booking or contacting you at all.
- Problems on key pages. Fix the home page, navigation, contact form, checkout and top landing pages before older blog posts.
- Problems in templates. A fault in the header, footer or product template repeats on every page, so one fix can clear hundreds of findings.
- Contrast and focus. These affect many visitors and are usually fixed in the stylesheet in one place.
- Content problems. Alt text, link text and headings are fixed page by page, so build them into how content is written and reviewed.
A sensible order of work
- Run the Accessibility Audit on the home page and on one page of each template.
- Group the findings by template, so each fix is made once at source.
- Fix blocking problems first: keyboard traps, unlabelled fields and unnamed buttons.
- Fix contrast and focus styles in the stylesheet.
- Test each key journey with only a keyboard, then with a screen reader.
- Fix content issues such as alt text, link text and headings, and add them to your publishing checklist.
- Publish an accessibility statement saying what you have tested, what is known not to meet WCAG and how people can ask for help.
- Run the checker again after every design change or new plugin.
For the full reference, see the Accessibility Guide, the example report or the beginner tutorial.
1. What is WCAG 2.2 level AA?
WCAG 2.2 is the current version of the Web Content Accessibility Guidelines published by the W3C. Its success criteria are grouped into three levels: A is the minimum, AA is the level most laws and policies refer to, and AAA is the highest and is not expected across whole sites. Meeting level AA means meeting every level A and level AA success criterion on the pages and processes being assessed.
2. Is website accessibility a legal requirement in the UK?
For public sector bodies, yes: the 2018 accessibility regulations require WCAG 2.2 AA and an accessibility statement. For businesses and charities, the Equality Act 2010 requires reasonable adjustments so disabled people are not put at a substantial disadvantage, and that applies to websites and apps. It does not name WCAG, but WCAG AA is the usual benchmark. Businesses selling into the EU may also be covered by the European Accessibility Act.
3. What colour contrast ratio do I need?
At least 4.5 to 1 between normal text and its background, and at least 3 to 1 for large text, which means about 24 pixels regular or 18.7 pixels bold. Icons, form field borders and focus outlines need at least 3 to 1 against what surrounds them. Check brand colours early, because a pale grey on white or white text on a bright brand colour is the most common failure the checker reports.
4. Do decorative images need alt text?
They need an alt attribute, but it should be empty: alt followed by two quotation marks with nothing between them. That tells screen readers to skip the image. Leaving the attribute out entirely is a failure, because many screen readers then read out the file name instead. Only use empty alt text when the image adds nothing to the meaning; if it carries information, describe that information briefly and leave out phrases like image of.
5. Can an accessibility overlay make my site compliant?
No. Overlay widgets add a toolbar or script on top of the site, but they do not fix missing labels, keyboard traps, poor headings or wrong alt text in the underlying code, and they can interfere with the screen readers and settings disabled people already use. Many accessibility specialists and disabled users advise against them. The reliable route is fixing the templates, styles and content themselves, then testing with a keyboard and a screen reader.
6. How do I test my site with a keyboard?
Put the mouse aside, click in the address bar and press Tab repeatedly. You should see a clear outline move through every link, button and field in a sensible order, never disappear behind a header or banner, and never get stuck. Enter should follow links and press buttons, Space should tick boxes, and Escape should close menus and pop-ups. Anything you cannot reach or operate this way is a failure to fix.
7. Does accessibility help SEO?
Yes, indirectly. Many accessibility fixes help search engines and AI tools understand a page too: descriptive alt text, a clear heading structure, real links with meaningful text, labelled forms and text rather than text inside images. Accessible pages also tend to be easier for everyone to use, which supports engagement. Accessibility is worth doing for people first, but the search benefits are a genuine bonus that comes with it at no extra cost.
The Accessibility Audit tests your page against WCAG 2.2 level AA, lists each finding with the element that failed and the success criterion behind it, and links to the guide that fixes it.
Run the Accessibility Audit →