Website accessibility checklist: WCAG basics and your accessibility statement

Why website accessibility matters

Website accessibility means people with disabilities can perceive, understand, navigate and use your site. That includes people who are blind and use screen readers, people with low vision who zoom or use high contrast, people who can't use a mouse, people who are deaf and rely on captions, and people with cognitive or learning disabilities.

There are three practical reasons to take it seriously:

• Legal and contractual. Accessibility requirements apply to public sector websites in the UK and EU, to many consumer-facing services in the EU under the European Accessibility Act from June 2025, and under disability discrimination laws in many countries, including the ADA in the United States. Schools, care providers, training providers and firms selling to the public sector are often asked about it in procurement.
• Customers. A form that can't be completed with a keyboard is a lost enquiry.
• Quality. Clear headings, readable contrast, descriptive links and labelled forms make the site easier for everyone, and help search engines and AI assistants understand it.

This is a jurisdictional area. This guide covers the common standard (WCAG) and the main laws in plain terms; it isn't legal advice.

WCAG in brief

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the standard almost every law and policy points to. The current version is WCAG 2.2.

WCAG is organised around four principles. Content must be:

1. Perceivable: people can see or hear it, in some form (alt text, captions, contrast).
2. Operable: people can use it with different inputs (keyboard, enough time, no seizure risks).
3. Understandable: content and controls are clear and predictable (labels, error messages, plain language).
4. Robust: it works with assistive technologies (valid code, proper names and roles).

Each requirement has a level: A (minimum), AA and AAA. Level AA is the usual target, and the one most regulations and buyers ask for.

The website accessibility checklist

This WCAG checklist covers the issues that most often fail on business websites, in plain language. It isn't every WCAG criterion, but it's where most real problems are.

How to write good alt text

Alt text is the text a screen reader reads instead of an image. It also shows if the image fails to load.

• Describe the purpose, not just the picture. For a photo of your team on a service page: "Our five-person support team at the [city] office", not "image of people".
• Keep it short: usually a sentence or less.
• Don't start with "Image of" or "Photo of"; screen readers already announce it's an image.
• Images that are links need alt text that says where the link goes.
• Charts and diagrams need the key point in the alt text, with the full data in the page text or a table.
• Decorative images (backgrounds, flourishes) should have empty alt text so screen readers skip them.
• Text in images should be repeated in the alt text, or better, written as real text.

How to test your site's accessibility

Use three kinds of testing together. Automated tools are quick, but they can only detect a portion of WCAG failures; many issues need a person to judge.

1. Automated checks

Run an accessibility checker on your key pages: homepage, main service pages, contact page and any forms. Browser extensions and audit platforms will flag missing alt text, low contrast, missing labels and heading problems.

2. Keyboard test

Put the mouse aside and use only the Tab key (Shift+Tab to go back), Enter and Space:

• Can you reach the menu, every link and every form field?
• Can you always see where you are?
• Can you open and close the menu, the cookie banner and any pop-ups?
• Can you submit the contact form?

3. Screen reader and zoom test

Try your key pages with a screen reader: VoiceOver is built into Mac and iPhone, and NVDA is a free option for Windows. Listen to whether headings, links, buttons and form fields make sense. Then zoom the browser to 200% and check nothing overlaps or disappears.

Accessibility audit template

Record each issue so it can be prioritised and fixed:

Fix blockers first: anything that stops someone completing a key task, such as contacting you.

What is an accessibility statement?

An accessibility statement is a page that explains how accessible your website is, what you're doing about known problems, and how people can get help or information in another format. Public sector bodies in the UK and EU are required to publish one in a set format. For other businesses it's good practice, it's increasingly asked for in procurement, and it shows you take accessibility seriously.

What to include in an accessibility statement

1. Your commitment: a short statement that you want the site to be usable by as many people as possible.
2. The standard you aim for: for example, WCAG 2.2 level AA.
3. Conformance status: fully, partially or not compliant, and how you assessed it (self-assessment or an external audit, and when).
4. Known issues: what doesn't yet meet the standard, in plain language, and when you plan to fix it.
5. Alternatives: how someone can get information in another format, such as by phone or email.
6. Feedback and contact: how to report a problem, and how quickly you'll respond.
7. Date: when the statement was written and last reviewed.
8. Enforcement procedure: required for public sector bodies, which must say how to escalate a complaint.

Accessibility statement template

Accessibility statement for [website]

[Business name] wants as many people as possible to be able to use this website. We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA.

How accessible this website is. This website is [fully / partially] compliant with WCAG 2.2 AA. We know some parts are not yet fully accessible: [list known issues, e.g. "some older PDF documents are not fully accessible to screen readers"]. We plan to fix these by [date].

Getting information in another format. If you need information on this website in a different format, contact us at [email] or [phone] and we'll respond within [number] working days.

Reporting problems. If you find a problem not listed here, please tell us at [email].

How we tested this website. This website was last tested on [date] by [us / name of auditor], using [automated checks, keyboard and screen reader testing].

This statement was prepared on [date] and last reviewed on [date].

The W3C also provides a free accessibility statement generator, linked in the sources.

Keep it accessible

Accessibility slips as content is added. Build a few checks into everyday publishing: alt text on every new image, headings in order, descriptive link text, captions on new videos, and a keyboard test of any new form or pop-up. Re-check the key pages at least once a year, and update your statement when you do.