Web Accessibility Guide: How to Make Your Website WCAG Compliant

Web accessibility means building websites that work for everyone — including the estimated 1 in 5 people in the UK who have some form of disability. Beyond the ethical case, accessible websites often rank better, convert better, and are legally required for public sector organisations. This guide gives you the practical steps.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines — a set of internationally recognised standards produced by the World Wide Web Consortium (W3C). The current version is WCAG 2.2, published in October 2023.

WCAG guidelines come in three conformance levels:

• Level A — the minimum. Failing these criteria creates significant barriers for disabled users.
• Level AA — the target for most organisations. UK public sector regulations require Level AA. This is the standard most businesses should aim for.
• Level AAA — the highest standard. Not required for most sites, and may be impractical for some content types.

The four WCAG principles

WCAG is built around four principles, summarised as POUR:

• Perceivable — users must be able to perceive all information. This includes text alternatives for non-text content, captions for video, and content that doesn't rely on colour alone to convey meaning.
• Operable — all functionality must be accessible via keyboard, not just a mouse. Users must have enough time to read and interact with content.
• Understandable — content must be readable and understandable. Inputs must have clear labels. Error messages must explain what went wrong and how to fix it.
• Robust — content must be interpreted reliably by assistive technologies like screen readers, now and in the future.

Who needs to comply?

In the UK, the Public Sector Bodies Accessibility Regulations 2018 require all public sector websites and apps to meet WCAG 2.1 Level AA. This applies to government bodies, NHS services, universities, and local councils.

For private businesses, there's no specific UK legislation mandating WCAG compliance yet. However:

• The Equality Act 2010 requires businesses to make "reasonable adjustments" for disabled users — which courts have increasingly interpreted to include digital services.
• The European Accessibility Act (coming into force across the EU from 2025) will affect any UK businesses serving EU customers.
• Beyond legal compliance, inaccessible sites exclude up to 20% of potential customers.

Keyboard navigation

Many users navigate entirely by keyboard — either because they can't use a mouse (due to motor disabilities) or because they prefer it (power users, screen reader users). Test your site by pressing Tab to navigate between interactive elements:

• Every interactive element (links, buttons, form fields) must be reachable via Tab
• There must be a visible focus indicator (don't hide the outline with outline: none without providing an alternative)
• Dropdown menus must be operable via keyboard
• Modal dialogs must trap focus while open and return focus when closed
• A "skip to main content" link at the top of the page helps keyboard users bypass repeated navigation

Colour contrast

WCAG Level AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold and above). Low contrast text is one of the most common accessibility failures.

Check your contrast ratios with:

• WebAIM Contrast Checker — free tool at webaim.org/resources/contrastchecker/
• Colour Contrast Analyser — desktop app that lets you eyedrop colours from any screen
• Chrome DevTools — click any text element and see the contrast ratio in the Styles panel

Alt text for images

Every meaningful image needs descriptive alt text. Screen readers read this text aloud to visually impaired users. Images that are purely decorative should have empty alt text (alt="") so screen readers skip them.

Good alt text:

• Describes the image's content and purpose
• Is concise (typically under 100 characters)
• Doesn't start with "image of" or "photo of" (screen readers already announce it's an image)
• For complex images (charts, graphs), provides a fuller description in the surrounding text

Accessible forms

Forms are one of the most common accessibility failure points:

• Every input must have a visible, associated label — use <label for="..."> linked to the input's ID, not just placeholder text
• Error messages must be specific — "Invalid input" is useless. "Please enter a valid email address" is helpful.
• Required fields must be clearly indicated
• Form submission errors must be announced to screen readers — use ARIA live regions or focus management
• Don't rely on colour alone to indicate errors (add an icon or text)

Semantic HTML and ARIA

Use HTML elements for their intended purposes. A <button> is always better than a <div onClick> for interactive elements. A <nav> element provides navigation context that a <div> doesn't.

ARIA (Accessible Rich Internet Applications) attributes add accessibility semantics where HTML alone isn't sufficient — for example, on custom dropdown menus, tab panels, or modals. The rule: use native HTML first, reach for ARIA only when HTML can't do what you need.

Screen reader testing

The ultimate test of your site's accessibility is using it with a screen reader. Free options:

• NVDA (Windows, free) — most widely used screen reader
• VoiceOver (Mac/iOS, built-in) — excellent for testing on Apple devices. Press Cmd+F5 to activate.
• TalkBack (Android, built-in) — for testing on Android devices

Free accessibility testing tools

• Axe DevTools (Chrome extension) — automated accessibility testing built into DevTools
• WAVE (wave.webaim.org) — visualises accessibility errors directly on the page
• Lighthouse (Chrome DevTools) — includes an accessibility audit as part of its report
• GradeMysite — our free website audit includes an accessibility score based on common WCAG criteria

Also read our website audit guide to understand all the factors that affect your site's quality.