Ensuring Website Accessibility: A Guide for UK Healthcare Providers

Introduction to Healthcare Website Accessibility in the UK

Healthcare website accessibility UK is central to fair access for every patient, carer, and referrer. If people cannot read your content, book an appointment, use assistive technology, or understand a form, they are excluded at the digital front door.

Two legal frameworks underpin this duty. The Equality Act 2010 places a responsibility on service providers to make reasonable adjustments for disabled people. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require public organisations to meet recognised standards and publish an accessibility statement. While many independent providers are not directly in scope of the Regulations, the same principles now shape public expectation, commissioning requirements, and clinical governance.

NHS Digital guidance sets practical expectations, including alignment with WCAG and current “NHS website accessibility” practices. The Care Quality Commission (CQC) also assesses how providers give people accessible information and make it easy to get help, which can feed into Safe, Effective, Responsive, and Well-led judgements.

This series explains what to prioritise, what evidence to keep, and how to brief your developer and budget.

Understanding NHS Website Accessibility Standards

Across the NHS, the benchmark for NHS website accessibility is WCAG 2.2 at AA level. These success criteria set the minimum standard public bodies are expected to meet under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, alongside publishing an accessibility statement. Many independent providers work to the same bar because commissioners, referrers, and patients now expect it. If you serve NHS patients, aligning with WCAG 2.2 AA is a practical baseline for WCAG compliance healthcare.

WCAG groups requirements under four plain ideas: content must be perceivable, operable, understandable, and robust. In practice, that means tasks such as booking, paying, reading fees, or downloading leaflets should be possible with a keyboard, readable by screen readers, clearly labelled, and presented with sufficient colour contrast and focus indicators. Government guidance points to WCAG 2.2 AA as the reference standard, and explains the accessibility statement duty, complaints route, and enforcement model Understanding accessibility requirements for public sector websites and apps. The NHS Service Manual has adopted WCAG 2.2 and flags what designers and developers should adjust New criteria in WCAG 2.2 – NHS digital service manual.

WCAG 2.2 AA is the floor for NHS websites, not a stretch target.

NHS Digital’s design patterns turn those principles into practical choices: accessible form components with clear labels and errors, enlarged hit areas for touch, consistent link styles, and guidance on content tone and reading level. Using these patterns reduces guesswork, and, for mixed NHS and private practices, keeps journeys consistent across channels. Ask your developer to start with the NHS components and spacing rules, then apply your brand carefully. If you are commissioning a rebuild, make WCAG 2.2 AA a non‑negotiable in your brief, and budget for accessibility testing or an healthcare website design partner who can support it.

Getting this right improves safety and clarity. Better contrast, predictable forms, and visible focus states make it easier to book the right appointment, read pre‑visit instructions, or request help, which tends to reduce errors and complaints. It also strengthens your evidence for commissioners and CQC, who assess how you provide accessible information to people using your service Providing information. From a legal perspective, aligning with the Regulations and publishing an accessibility statement lowers the risk of challenge; public sector enforcement routes exist, and are publicly documented by the Equality and Human Rights Commission How to report an inaccessible public sector website.

WCAG Compliance for Healthcare Websites

For UK providers, WCAG 2.2 AA is the practical benchmark to aim for. While the Public Sector Bodies Accessibility Regulations require conformance against WCAG AA and an accessibility statement, many healthcare teams now work to 2.2 because it reflects current user needs, including clearer focus indicators and reduced re‑entry of data. The NHS Service Manual summarises the new 2.2 criteria and is a reliable reference for teams aligning their websites and apps to the latest expectations New criteria in WCAG 2.2 – NHS digital service manual. Public bodies should also follow the Government’s guidance on publishing an accessibility statement Understanding accessibility requirements for public sector websites and apps.

A sound approach to WCAG compliance healthcare work is structured and repeatable: audit, remediate, test with assistive technologies, then monitor and update. Use semantic HTML first (proper headings, lists, landmarks, and form labels), add ARIA only where needed, and keep interaction patterns predictable.

Accessibility essentials checklist (aim for WCAG 2.2 AA healthcare):

• [ ] Structure: one H1 per page, logical H2–H4 order, landmarks (header, nav, main, footer).
• [ ] Keyboard: all content and controls operable without a mouse; visible, high‑contrast focus.
• [ ] Forms: associated labels, clear instructions, descriptive errors, reduced re‑entry (2.2 3.3.7).
• [ ] Media: captions for videos, transcripts for audio, descriptive alt text for meaningful images.
• [ ] Contrast and size: meet AA colour contrast; touch targets meet minimum sizes (2.2 2.5.8).
• [ ] Motion and input: provide alternatives to dragging (2.2 2.5.7); avoid content that flashes.
• [ ] Authentication: no complex puzzle or memory tests; allow copy‑and‑paste (2.2 3.3.8/3.3.9).
• [ ] Content: plain English, consistent navigation, avoid only‑colour cues and tiny text.
• [ ] Documents: provide accessible HTML or tagged PDFs; avoid scans.
• [ ] Third‑party widgets: booking, chat, and payment tools tested for accessibility.

Testing and evidence checklist:

• [ ] Run automated checks (e.g., axe, WAVE) to catch common issues, then manual reviews.
• [ ] Test with assistive tech: screen readers (NVDA/JAWS/VoiceOver), TalkBack, speech recognition.
• [ ] Check zoom up to 400%, reflow on small screens, and keyboard‑only operation.
• [ ] Observe real users, including staff with access needs, completing key tasks (book, pay, contact).
• ] Record defects, fixes, and retests; publish and maintain an accessibility statement (update at least annually) [Understanding accessibility requirements for public sector websites and apps.

Benefits typically include fewer barriers for patients and carers, lower legal risk, and smoother journeys that reduce support time. Accessibility also intersects with privacy: forms, cookies, and consent banners must be usable by everyone; see our guide on meeting the ICO’s expectations Ensuring Your Healthcare Website Meets ICO's Accessibility Standards.

CQC's Role in Healthcare Website Accessibility

The Care Quality Commission assesses how people access your services online as part of its “responsive” and “well-led” judgements. Under the Single Assessment Framework, inspectors look for evidence that people can find, understand, and use information and digital routes to care, and that the service adapts to different needs and preferences. This includes how clearly you explain services and fees, how a person books or requests help, and whether alternative contact routes are easy to find for those who cannot use the website. The CQC’s guidance on the Responsive quality statement “Providing information” sets this expectation out for all providers Providing information.

CQC also expects providers to meet their legal duties under the Equality Act 2010 and to provide accessible information. If you deliver NHS care or publicly funded adult social care, you must follow the Accessible Information Standard (AIS): identify people’s communication needs, record and flag them, and give information in formats they can use Accessible Information Standard. Private healthcare providers who are not subject to AIS should still make reasonable adjustments online, such as captions, readable layouts, and easy routes to human support.

There are no standalone CQC accessibility standards for websites. Instead, CQC accessibility requirements sit within the quality statements and the evidence they expect to see. Typical evidence includes: user-friendly content written in plain English; WCAG-aligned design choices that remove barriers; an accessibility statement and a way to request information in alternative formats; staff training and governance that show accessibility is owned, measured, and improved; and feedback and complaints data used to fix digital barriers promptly.

Digital access affects ratings and public trust. Poor accessibility can indicate risks under “responsive” (people face avoidable barriers) and “well-led” (leaders are not prioritising equitable access). Strong evidence of inclusive digital journeys usually supports better findings. Your rating is also public; how you present it on your site influences credibility, so make sure you display it correctly and clearly Displaying CQC Ratings on Your Healthcare Website. Publish what you are improving next, and invite feedback from patients and carers about accessing services online.

Tools and Best Practices for Ensuring Accessibility

Treat healthcare website accessibility testing as a routine, not a one‑off. Use a blend of automated and manual checks: axe DevTools and WAVE for quick issue spotting, plus keyboard‑only journeys, zoom to 400%, and real device checks on mobile. Add screen reader runs that cover key tasks, such as booking, contact, and finding fees. Test with NVDA or JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android to catch issues automation misses.

Bake accessibility into your design system. Define tokens for colour contrast, spacing, and focus outlines; document components with required labels, error patterns, and keyboard behaviour; and prefer semantic HTML over ARIA wherever possible. Provide code snippets, content standards, and editorial patterns that avoid ambiguity in link text, headings, and calls to action.

Set a cadence: automated checks on every commit, a weekly or sprint audit across priority templates, and a quarterly assisted‑tech review with short patient tasks. Keep an issue log with owners and dates, and publish your accessibility statement with contact routes for alternative formats. For reference, see the NHS digital service manual accessibility guidance, including the updated WCAG 2.2 criteria, and the GOV.UK overview of public sector accessibility requirements, which remains a helpful benchmark. NHS digital service manual accessibility guidance · Overview of public sector accessibility requirements

• Use semantic HTML: headings in order, lists for lists, buttons for actions, and landmarks for regions.
• Design clear navigation: consistent menus, visible focus, skip links, and descriptive link names.
• Make media accessible: captions and transcripts, meaningful alt text, audio descriptions where needed, and controls for autoplay or motion.
• Build resilient forms: explicit labels, helpful hints, accessible error messages, and no reliance on colour alone.

Assign ownership. Nominate a design lead for patterns, a developer for audits, and an editor for content quality, then review as a triad before releases. Keep a short changelog of accessibility fixes and open issues. Train staff annually, and refresh when WCAG updates add new criteria such as focus appearance and drag alternatives. Small, regular improvements usually beat large, infrequent rebuilds.

Accessibility supports trust, safety, and credible evidence across your site; see our overview of Healthcare Compliance & E-E-A-T for how it ties into wider governance.

Conclusion and Call to Action

Meeting accessibility standards is not only a technical exercise; it is a commitment to equity. Accessible sites welcome more patients, reduce barriers to care, and lower exposure to complaints, enforcement, and inspection findings. Aligning with WCAG and the Accessible Information Standard helps you evidence reasonable adjustments, while reducing costly rework and reputational risk.

Sustained results come from proactive governance. Set an audit rhythm (for example, quarterly automated checks and an annual manual review), track issues in a simple register, and make one owner accountable for closing them. Test new features before release, train editors on headings, alt text, and link wording, and re-check when WCAG criteria change.

Aethus supports clinics and developers with tailored accessibility strategy, audits, and pragmatic fixes. If you want a quick sense check, book a free 20‑minute website review; we highlight priority issues and opportunities. For deeper help, we align healthcare website accessibility UK requirements with your content, templates, and workflows, and shape a roadmap your team can own. Start here: Book a Website Review. We reply within one working day.

Frequently Asked Questions

Is website accessibility a legal requirement in the UK?

Yes. Private healthcare providers have duties under the Equality Act 2010 to make reasonable adjustments for disabled people, which includes digital services. NHS organisations and other public bodies also fall under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, which require accessible websites and apps and a published accessibility statement. See the GOV.UK guidance on these regulations for details: Understanding accessibility requirements for public sector bodies (websites and apps) (GOV.UK).

Understanding accessibility requirements for public sector bodies — GOV.UK

What accessibility standards must NHS websites meet?

Under the Public Sector Bodies Accessibility Regulations 2018, NHS websites are expected to meet WCAG 2.2 AA as the baseline, unless a specific criterion would be a “disproportionate burden”. The NHS service manual also reflects the WCAG 2.2 updates and expectations.

• The Regulations (legislation): The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
• NHS direction: New criteria in WCAG 2.2 – NHS digital service manual.

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 New criteria in WCAG 2.2 – NHS digital service manual

What is the NHS Accessible Information Standard (AIS)?

AIS is a legal standard for NHS care and publicly funded adult social care. It requires services to identify, record, flag, share, and meet people’s communication needs relating to disability, impairment, or sensory loss. It complements web accessibility by covering appointment letters, leaflets, emails, SMS, and alternative formats, such as large print, Braille, and BSL.

Accessible Information Standard — NHS England

How do I test a healthcare website for WCAG 2.2 compliance?

Use both automated and manual checks. Run automated tests with tools such as axe DevTools and Lighthouse to catch common issues. Then test manually: navigate every page and form using only a keyboard, try screen readers (NVDA, VoiceOver, or TalkBack), zoom content to 400%, check visible focus, heading order, link purpose, error messages, and mobile touch targets.

See more on Healthcare Compliance.

Compliance for practices — Book a Website Review

This article covers how a practice runs and markets itself. It is not clinical advice and does not replace guidance from your regulator or professional body.