WCAG 2.2 and primary care websites: what matters in practice

WCAG provides testable criteria for making web content more perceivable, operable, understandable and robust. WCAG 2.2 builds on earlier versions and the NHS digital service manual uses WCAG 2.2 as its current accessibility reference.

For delivery teams, this means accessibility needs to be translated into design and development decisions: keyboard-operable controls, meaningful labels, sufficient contrast, logical focus movement, usable forms and content structures that assistive technology can understand.

Compliance should not become a checklist detached from users. Passing individual criteria is important, but a technically conformant page can still be confusing. User testing and practical journey testing remain necessary.

People who cannot use a mouse may navigate through links, buttons and form fields using a keyboard or an assistive device that behaves like one. Every interactive control therefore needs to be reachable and usable without pointer input.

Focus also needs to be visible. Users should be able to tell which element will respond when they press Enter, Space or another key. Removing browser focus outlines without providing an equivalent replacement is a common accessibility failure.

WCAG 2.2 adds further attention to focus not being obscured by other content. Sticky headers, cookie banners and floating elements need to be considered so that the focused control does not disappear behind them.

Primary care websites are frequently used on phones, making touch interaction particularly important. Links and controls positioned too closely together can be difficult for people with reduced dexterity and frustrating for everyone.

WCAG 2.2 introduces a minimum target-size criterion at AA level, subject to its defined exceptions. Rather than designing to the smallest technically permissible target, teams should provide comfortable spacing wherever possible.

Responsive testing should also consider whether menus, accordions, appointment links and external service buttons remain understandable when the page is narrow and text is enlarged.

Technical accessibility cannot compensate for confusing healthcare content. Patients need to understand what a service is, whether it is appropriate for them and what they should do next.

The NHS service manual places strong emphasis on plain English and health literacy. Medical terminology, complex sentence structures and unexplained acronyms can prevent people from acting on information even when the page is technically accessible.

Content should be organised around user questions rather than internal organisational structures. Headings need to describe the information beneath them, and important instructions should not be buried inside long paragraphs.

Forms are often where accessibility problems become operational problems. Every field needs a programmatically associated label, and required information should be communicated clearly rather than relying only on colour.

Errors should explain what went wrong and how to fix it. Where several errors exist, an error summary can help users understand the overall state of the form and move to the relevant fields.

Authentication journeys deserve particular consideration. WCAG 2.2 includes accessible-authentication criteria intended to reduce barriers created by cognitive-function tests. Healthcare services that depend on external authentication should still evaluate the complete user journey rather than assuming responsibility ends when the visitor leaves the practice website.

Meaningful images should have alternative text that communicates their purpose in context. Decorative imagery generally should not create unnecessary noise for screen-reader users.

PDFs and other downloadable documents can create additional barriers and should not become the default format for information that could be presented effectively as accessible HTML.

Third-party services also form part of the patient journey. A practice may not control the code of an external booking or consultation platform, but it should still understand whether the transition is clear and provide appropriate alternatives or support where required.

Automated tools are useful for detecting particular technical problems such as some contrast, labelling and structural issues. They cannot establish whether an entire healthcare journey makes sense.

Manual keyboard testing, zoom and responsive testing, screen-reader checks and review of content structure add different forms of evidence. Testing should include representative templates and important tasks rather than checking only the homepage.

Where possible, research with people who have access needs provides insight that technical audits cannot. It can reveal confusing language, unexpected navigation behaviour and practical barriers that are otherwise easy to miss.

A website can launch in a strong state and become less accessible as content changes. New pages, plugins, documents and third-party embeds can introduce problems over time.

Editors need guidance as well as developers. Heading hierarchy, link wording, alternative text and document publishing are content-management responsibilities.

Regular checks, an accurate accessibility statement and a process for responding to reported problems turn accessibility into ongoing governance rather than a one-off project milestone.

A good primary care website should make essential journeys obvious, work across devices and input methods, use understandable content and remain maintainable by the team responsible for it.

Accessibility should therefore be considered during discovery, content design, interface design, engineering, testing and ongoing support. Treating it as a final compliance exercise makes problems more expensive to correct and usually produces a poorer experience.

When accessibility is built into normal digital delivery, the result is not simply a more compliant website. It is a clearer and more dependable healthcare service for everyone who needs to use it.