Millions of people in the UK alone have a disability or impairment that affects how they use the web.
Some use screen readers, some navigate your website by tabbing (using a keyboard instead of a mouse), and some simply struggle to read pale grey text on a white background.
If your website doesn’t work for them, you’re losing customers, donations and enquiries. That’s a big deal. It’s also a legal risk: under the Equality Act 2010, businesses are expected to make reasonable adjustments, and WCAG 2.2 AA is the widely used benchmark for what that looks like online.
First up, what is WCAG 2.2 AA?
For those of you who may not know the ins and outs, WCAG stands for the Web Content Accessibility Guidelines. They’re the internationally recognised standard for making websites usable by people with disabilities, published by the W3C (the organisation behind the web’s core standards). Version 2.2 is the current release.
The guidelines are built around four leading principles. Your site should be:
- Perceivable - people can see, hear or otherwise take in the content of your site (such as providing text alternatives for images, and enough colour contrast)
- Operable - people can navigate and use your site with a keyboard, mouse, touch or assistive tech
- Understandable - content and interactions are clear and predictable
- Robust - it works reliably across browsers and assistive technologies
Each requirement is graded at one of three levels: A (the essential minimum), AA (the level most laws, public bodies and organisations aim for) and AAA (the most demanding, not usually expected across a whole site). Aiming for AA is usually the recommended route.
Here are some helpful resources to help you wrap your head around it all:
- WCAG 2.2 - the full specification
- How to Meet WCAG 2.2 - the quick reference, which is filterable and much easier to browse
- WCAG 2 at a Glance - a plain-English overview
So, how can I test my website?
The good news is that you can spot the most common problems in about ten minutes. Grab a coffee and open your homepage. ☕
1. The keyboard test (2 minutes)
Put your mouse aside and press Tab repeatedly to move through the page.
On a Mac in Safari, press Option + Tab to reach links, or turn on “Press Tab to highlight each item on a webpage” in Safari’s settings (under Advanced) - otherwise Tab skips links by default.
- Can you reach every link, button and form field?
- Can you see where you are? There should be a clear outline or highlight on the focused item.
- Can you open menus and close pop-ups without a mouse?
If focus disappears or you get stuck, keyboard and screen reader users will too.
2. The zoom test (1 minute)
Zoom your browser to 200% (Ctrl/Cmd and +). Is all the text still there and readable, or does anything overlap, get cut off or vanish? Plenty of people rely on zoom, and a good site should adapt gracefully.
For a tougher test, try 400% - the content should reflow into a single column, so you never have to scroll sideways to read it.
3. The contrast check (2 minutes)
Light grey text on white looks elegant, but it’s one of the most common accessibility failures out there. Paste your text and background colours into a free tool like the WebAIM Contrast Checker. For normal-sized text, aim for a ratio of at least 4.5:1. Don’t forget buttons, placeholder text and text over images.
4. The alt text check (1 minute)
Right-click an important image and inspect it, or use a browser extension that shows alt attributes. Meaningful images should have a short description of what they show or do. Purely decorative ones should have empty alt text so screen readers skip them. “image123.jpg” doesn’t count. 😄
5. The heading check (2 minutes)
Headings are how screen reader users skim a page, like a table of contents.
- Best practice is one H1 per page.
- Headings should ideally follow a logical order (H1, then H2, then H3), not be chosen for how big they look.
- Don’t use bold text in place of a proper heading.
A free tool like the WAVE browser extension shows the structure at a glance.
6. The forms check (2 minutes)
Try filling in your contact form.
- Does every field have a visible label (not just placeholder text that vanishes when you type)?
- Are error messages clear, and do they say what went wrong and how to fix it?
- Can you submit it using the keyboard alone?
Bonus: run an automated scan
Free tools like Lighthouse (built into Chrome), WAVE and axe DevTools will flag many issues in seconds. Treat them as a starting point, though. Automated tools only catch a portion of accessibility problems, so the manual checks above still matter.
So, how did you do?
If everything passed, great work! If you found a few issues, you’re in good company, as most websites do. The key is to fix the biggest barriers first and make accessibility part of how you build, rather than something bolted on at the end.
Accessibility sits alongside performance and sustainability as part of building a better web. If you read our post on website carbon, you’ll know that a lean, well-built site is faster, greener and easier for everyone to use.
Practising what we preach
We hold our own website to the same standard. It’s built to meet WCAG 2.2 AA, we check every page with automated tools and by hand, and animations switch off automatically if you’ve asked your device to reduce motion. You can read exactly what we’ve done, and how to tell us if something isn’t working for you, in our accessibility statement.
Want a more accessible website?
Want a second pair of eyes? At Duology, we build accessibility into every project from day one, and we can review your existing site too - checking it against WCAG 2.2 AA and giving you a clear, prioritised list of what to fix first.
Book a 30-minute call and we’ll talk through where your site stands.
Sources
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C
- Equality Act 2010, legislation.gov.uk
- Contrast Checker, WebAIM