Website accessibility in the UK: the Equality Act 2010 and WCAG

Around the UK, people use websites with screen readers, keyboards instead of a mouse, magnification, captions and voice control. If your website does not work with these, some customers cannot buy from you, book with you or contact you. This guide explains how the Equality Act 2010 applies to business websites, when the stricter public sector rules apply, and how to use the Web Content Accessibility Guidelines (WCAG) as a practical benchmark. It is general information, not legal advice; for advice about your organisation, see the Equality and Human Rights Commission (EHRC) or a solicitor.

Does the Equality Act 2010 apply to your website?

In England, Scotland and Wales, the Equality Act 2010 applies to service providers: businesses, charities, clubs and public bodies that provide goods, facilities or services to the public. The EHRC's guidance says it does not matter whether the service is free or paid for, or how large the organisation is. It lists websites and internet services among the areas where service providers must avoid discrimination and, where necessary, make reasonable adjustments for disabled people. Northern Ireland has its own disability discrimination law, and the Equality Commission for Northern Ireland is the regulator there.

What does the duty to make reasonable adjustments mean?

The EHRC describes three requirements, which apply where a disabled person would otherwise be at a substantial disadvantage:

• Changing the way things are done: the law calls this a provision, criterion or practice, such as a rule that orders can only be placed through one inaccessible form.
• Physical features: mainly relevant to premises rather than websites.
• Auxiliary aids and services: providing extra help or a different way to use the service.

The duty is anticipatory. A service provider cannot wait until a disabled person tries to use the service; it must think in advance, and on an ongoing basis, about what people with a range of impairments might reasonably need. For websites, the EHRC says that where this is a reasonable adjustment, and it is likely to be, a website must be accessible to all users, including people who use text-to-speech software, people who cannot use a mouse, and people with dyslexia or learning difficulties.

What is reasonable depends on factors such as the size and nature of the organisation, the services it provides and the resources available. The EHRC also notes that many adjustments are not particularly expensive.

What about public sector websites?

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 apply to public sector bodies, such as central and local government, and to some charities and other organisations, unless they are exempt. GOV.UK says these websites and apps should meet WCAG 2.2 at level AA and must publish an accessibility statement. The Government Digital Service monitors a sample of sites each year, and the EHRC and the Equality Commission for Northern Ireland enforce the requirements.

A private business is not covered by these regulations, but the public sector approach is a useful model: a recognised standard, regular testing and an honest statement about what still needs work.

Why is WCAG 2.2 AA the usual benchmark?

WCAG is published by the World Wide Web Consortium (W3C). Version 2.2 is a W3C Recommendation, built on four principles: content must be perceivable, operable, understandable and robust. Each success criterion has a level: A, AA or AAA. The Equality Act does not name a technical standard, but WCAG 2.2 AA is the level the UK public sector uses and the one most organisations and developers work to. WCAG 2.2 added criteria that are easy to miss on older sites, such as making sure the keyboard focus is not hidden behind sticky headers or banners, giving controls a minimum target size, and keeping login steps accessible.

What should your accessibility checklist cover?

No checklist replaces a proper audit, but these checks catch many common problems:

• Keyboard: every link, button, menu, form and pop-up works with the keyboard alone, in a logical order, with a clearly visible focus indicator that is never hidden behind other content.
• Colour and contrast: normal text has a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. Colour is never the only way information is shown, for example in form errors.
• Images: meaningful images have short, accurate alternative text; decorative images are marked so screen readers skip them.
• Forms: every field has a visible label, required fields are clearly marked, and error messages explain what went wrong and how to fix it. Do not rely on placeholder text as the label.
• Login and checkout: people can paste passwords and use password managers, and there is no puzzle-style test without an accessible alternative.
• Video and audio: pre-recorded video has accurate captions, and audio content has a transcript.
• Headings and structure: each page has a descriptive title, one main heading and a logical heading order, and link text makes sense out of context.
• Zoom and mobile: content reflows when zoomed in without sideways scrolling, and buttons are large enough to tap.
• Movement: carousels and animations can be paused, and nothing flashes rapidly.
• Documents: important PDFs are accessible, or the same information is available as a web page.

How should you test your website?

The W3C says no tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation is needed. A sensible approach combines:

• automated checks with a browser extension or testing tool, to find missing labels, contrast issues and code errors quickly;
• manual testing with the keyboard only, at high zoom and on a phone;
• screen reader checks with tools such as NVDA on Windows and VoiceOver on Apple devices;
• feedback from disabled users, which the W3C recommends involving throughout a project.

Test a representative sample of pages and the key journeys: finding a product or service, filling in the contact form, booking and checking out. Re-test after redesigns, new features and plugin updates, because accessibility can break quietly. It is easier and cheaper to build accessibility into design and acceptance criteria from the start than to fix it afterwards.

What should an accessibility statement say?

Public sector bodies must publish one. For a private business it is optional but good practice. The W3C suggests that a statement should at least include:

• your commitment to accessibility for disabled people;
• the standard you work to, such as WCAG 2.2 level AA;
• contact details for people who run into problems or need information in another format.

It can also list known limitations and your plans to fix them, the browsers and assistive technologies you tested with, and the date of the last review. Keep it honest and specific: describe what you tested and what still needs work, rather than making broad claims about the whole site. Review it at least once a year, and whenever the site changes significantly.

If you are planning a new website or a rebuild, accessibility is easiest to get right in the design stage. See our website development in the UK and website development pages, read our guide to the ADA and WCAG if you also serve customers in the USA, or contact us to discuss an accessibility review.

Sources

• EHRC: Equality Act 2010 summary guidance on services, public functions and associations (PDF)
• GOV.UK: Understanding accessibility requirements for public sector bodies
• GOV.UK: Make your public sector website or app accessible
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI: Evaluating Web Accessibility Overview
• W3C WAI: Developing an Accessibility Statement