Topic hub

Website Accessibility

Website accessibility means designing content and interactions so people with different visual, hearing, motor and cognitive needs can use the service. It improves reach and resilience and should be integrated into…

1 published guides0 subtopicsUpdated 21 July 2026

Start here

The main guide for this topic

Practical guide

Website Accessibility Basics

Accessible foundations are usually ordinary good web practice: meaningful HTML, readable content, keyboard access, clear labels and visible feedback. Start with the barriers that prevent a task from b…

Open the complete guide →

Published guides

Articles in this section

Practical guide21 July 2026

Website Accessibility Basics

Accessible foundations are usually ordinary good web practice: meaningful HTML, readable content, keyboard access, clear labels an…

Read guide →

About this section

Information checked: 21 July 2026.

In brief: Treat accessibility as an ongoing product requirement, not a one-off score.

Use WCAG as a practical framework

WCAG principles in everyday website work
Principle	Practical question
Perceivable	Can people access information without relying on one sense?
Operable	Can every function be used with keyboard and other inputs?
Understandable	Are language, navigation and errors clear and predictable?
Robust	Does semantic markup work with browsers and assistive technology?

Prioritise real customer journeys

Navigation and search.
Forms, validation and confirmation.
Booking, payment and account access.
Documents and media.
Cookie and privacy controls.
Contact and complaints routes.

Combine methods

Automated tools identify selected technical issues but cannot judge whether instructions make sense, focus order is logical or an alternative text communicates the purpose. Use automated checks, keyboard review, screen-reader spot checks and testing with disabled users where proportionate.

Acceptance check

Accessibility is being managed when issues have owners, severity, deadlines and regression tests, and users have a working route to report a barrier or request an alternative.

Include accessibility in ordinary change control

A redesign, cookie banner or new booking widget can reintroduce barriers even after a successful audit. Add keyboard, focus, zoom, labels and error handling to the acceptance criteria for shared components and high-value journeys.

Records to keep

Accessibility backlog and severity.
Component-level regression checks.
User feedback and alternative-format requests.
Testing scope, method and date.

Owner test: Choose one recent feature release and show where accessibility was reviewed before publication and after deployment.

Third-party services remain part of the journey

Booking, payment, chat and consent tools can create the most serious barriers even when the main theme is accessible. Include them in procurement and acceptance checks. Ask suppliers for current accessibility information, test the embedded journey yourself and maintain an alternative route when the component cannot be fixed promptly.

Sources and date checked

This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.