NHS Accessibility Compliance: The Complete Guide For 2026

If you are responsible for an NHS Trust website in 2026, accessibility is not a design preference, a nice-to-have, or a phase-two item for the next refresh. It is a legal obligation, it is being actively monitored by the Government Digital Service, and the standard you are being measured against has changed.

The honest position is this: most NHS Trust websites in England are not fully compliant with the current legal standard. Many were built to WCAG 2.1 AA, which was the correct target at the time. Some were built to WCAG 2.0, which is now two versions behind. A few were never built to a formal accessibility standard at all. None of that is unusual. What has changed is that the regulator is now actively testing against a newer, stricter version of the guidelines, and the legal and reputational consequences of falling short are real.

This guide walks through where the law sits in 2026, what WCAG 2.2 AA actually requires that 2.1 did not, what is likely to be wrong with your current site, and the practical steps a communications or digital lead can take this quarter to close the gap. It is written for the people who usually get handed this problem: comms managers and digital leads, not developers. The technical detail is there when you need it, but kept in plain English throughout.

THE LEGAL POSITION IN 2026, IN PLAIN ENGLISH

NHS Trust websites are covered by two pieces of UK law that work in combination.

The first is the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, usually shortened to PSBAR 2018. These regulations require every public sector body in the UK, including NHS Trusts, to make their websites and mobile apps accessible, to publish an accessibility statement, and to meet a specific technical standard.

The second is the Equality Act 2010, which applies more broadly and requires service providers, including NHS organisations, to make reasonable adjustments so that disabled people are not put at a substantial disadvantage in accessing services. An inaccessible website can constitute a failure to make reasonable adjustments, and that is enforceable through the courts.

The technical standard that those regulations point to has changed. WCAG 2.2 was published by the W3C on 5 October 2023 and became the legal technical standard for the accessibility regulations from that date. GDS (the Government Digital Service, which took over monitoring from CDDO) has been actively testing public sector websites against WCAG 2.2 since October 2024. That means a Trust whose website still cites WCAG 2.1 in its accessibility statement, a common situation, is using the wrong reference.

Enforcement sits with GDS for the regulations themselves and with the Equality and Human Rights Commission for broader discrimination complaints. GDS monitors a sample of public sector websites every year and publishes non-compliance findings, including the name of the organisation. That public-naming element matters more than it sounds: it is trivially searchable, and it is one of the first things a journalist, a board member, or a rival Trust will find.

The most common misconception we hear from Trust comms teams is that accessibility compliance is essentially about making text bigger and adding alt tags to images. It is not. It is a structural, technical, and editorial standard that touches almost every aspect of how a website is built and managed. Which brings us to WCAG 2.2 itself.

WHAT WCAG 2.2 REQUIRES THAT 2.1 DIDN’T

WCAG 2.2 builds on WCAG 2.1 rather than replacing it. Everything in 2.1 still applies. What 2.2 adds are nine new success criteria and one removal (an older criterion about HTML parsing, which modern browsers now handle automatically).

For NHS Trusts targeting Level AA, which is what PSBAR 2018 requires, six of those nine new criteria are in scope. They are worth knowing about individually, because each one reflects a real accessibility gap patients and staff with disabilities have been experiencing for years.

• 2.4.11 Focus Not Obscured (Minimum). When a keyboard user tabs through a page, the element they have landed on must remain at least partly visible, not hidden behind a sticky header, a cookie banner, or a chat widget. This one catches out almost every website with a fixed navigation bar.
• 2.5.7 Dragging Movements. Any function that works by dragging, a map, a slider, a date picker, a reordering list, must have an alternative that works with a single tap or click. A patient with a motor disability using a head-tracked mouse cannot drag reliably; they need another way to do the same thing.
• 2.5.8 Target Size (Minimum). Clickable elements (links, buttons, form controls) must be at least 24 by 24 CSS pixels, or have enough spacing around them that accidental taps are not a problem. This matters enormously on mobile, where most NHS website traffic happens, and for older patients or anyone with hand tremor.
• 3.2.6 Consistent Help. If your site provides a help mechanism (a contact link, a phone number, a chat widget) it has to be in the same place on every page where it appears. Patients with cognitive disabilities should not have to re-learn your site’s layout on every page.
• 3.3.7 Redundant Entry. Forms cannot ask the same person for the same information twice in a single process unless there is a good reason to. If a patient has already given their date of birth in step one, step three cannot ask for it again without pre-filling it.
• 3.3.8 Accessible Authentication (Minimum). Login and verification cannot rely on a cognitive test that excludes users with memory or cognitive disabilities. Puzzle-based CAPTCHA, for instance, are a problem. Magic-link emails, password managers that can autofill, and biometric options all count as acceptable alternatives.

None of these criteria are exotic. They describe the kinds of problems real patients have been raising with Trusts for years. What has changed is that they are now formally part of the standard the regulator is testing against, which means they are part of the standard your Trust has to meet.

WHAT’S PROBABLY WRONG WITH YOUR TRUST WEBSITE RIGHT NOW

We have audited NHS Trust websites across England and the West Midlands, and there is a recognisable pattern of recurring issues. You will not have all of these, but if your site is more than three or four years old, you will likely have most of them.

• Colour contrast failures. Text, buttons, and form labels that do not meet the 4.5:1 contrast ratio required for normal text or 3:1 for large text. NHS brand colours are safe when used correctly, but many Trust sites drift into lighter greys, paler blues and washed-out calls to action that fail automatic contrast checks.
• Missing or decorative alt text. Images either have no alt attribute at all, have “image” or a filename as alt text, or, almost as common, have alt text that describes the image when it should be marked as decorative.
• Incorrect heading structure. Pages that skip heading levels (H1 straight to H3), use headings for visual styling rather than semantic structure, or have multiple H1s on a single page. Screen reader users rely on heading structure to navigate. A broken hierarchy makes the page genuinely unusable for them.
• Inaccessible PDFs. This is the one that blindsides most Trusts. Every board paper, service leaflet, visitor guide, annual report and clinical information sheet you have put on the site as a PDF is in scope. Untagged PDFs, scanned documents, forms that cannot be completed with a keyboard, all of these need fixing or replacing with accessible HTML equivalents.
• Forms without proper labels or error handling. Contact forms, appointment request forms, recruitment application forms, feedback forms, many are built without programmatically associated labels, without clear error messages, and without the kind of field grouping that makes them navigable with a screen reader.
• Missing keyboard navigation. Interactive elements (dropdowns, accordions, tabbed interfaces, carousels, search autocomplete) that work with a mouse but trap, skip, or fail under keyboard navigation. This is particularly common with custom components built before accessibility was a design priority.
• An outdated or incomplete accessibility statement. PSBAR 2018 requires a specific format including mandatory wording, an honest list of known accessibility issues, contact details for reporting new issues, and a last-reviewed date. Many Trust accessibility statements are older than the current version of the website, reference WCAG 2.1 instead of 2.2, or quietly omit known problems.
• Missing multimedia alternatives. Trusts rely heavily on video for patient information and board broadcasts. Missing closed captions, transcripts, or audio descriptions are major compliance gaps that often get overlooked when uploading new content.
• The third-party portal trap. We know comms teams often have zero control over external patient booking portals or Trac recruitment systems. But while you wait for those third-party vendors to catch up to the law, your main digital front door—the core platform you can control—needs to be bulletproof to limit your overall exposure.

Any one of these issues is enough to trigger a formal complaint. Several of them are enough to trigger a GDS detailed audit.

THE RISKS OF DOING NOTHING

It is worth being honest about what is at stake, because the risks of ignoring this are not hypothetical.

• Legal exposure is real. The Equality Act 2010 has been used successfully against public sector organisations for inaccessible digital services. The EHRC has the enforcement powers; individuals and advocacy groups have the standing to bring complaints; and legal costs for defending a claim vastly exceed the cost of fixing the underlying issues.
• Reputational damage is immediate. GDS publishes non-compliance findings with the name of the organisation attached. Local press pick these up. Patient groups pick these up. For a Trust already under CQC, funding or commissioner scrutiny, a published accessibility failure adds to an already difficult narrative.
• Funding windows close. NHS England’s digital transformation funding cycles are time-limited and competitive. Trusts that cannot evidence current digital compliance are at a measurable disadvantage when bidding for the next capital allocation.
• Patient trust erodes. This is the one that comms teams feel most acutely. A website that is visibly harder for disabled patients, older patients, or patients using mobile phones reflects on clinical quality in ways senior leadership does not always recognise. Your digital front door is a reputation asset or a reputation liability. It is rarely neutral.
• Staff frustration compounds. Your comms team is the one that fields complaints, handles accessibility queries, and gets asked to just fix issues on a CMS that often cannot be fixed without developer intervention. Over time, that slowly burns out good people.

WHAT TO DO THIS QUARTER: A PRACTICAL PLAN

Accessibility work has a reputation for being overwhelming, and it is easy to understand why. The full WCAG 2.2 standard runs to dozens of success criteria, and a realistic remediation programme for a large Trust website is a multi-month project. But the first steps are neither expensive nor technically difficult, and the right starting point depends less on your budget and more on getting a clear picture of where you currently stand.

1. Run an automated scan. An automated accessibility scan catches roughly 30 to 40 percent of WCAG issues, which sounds modest but actually gives you a very fast baseline. It identifies missing alt text, contrast failures, structural problems, form labelling issues, and a good proportion of the mechanical failures that would be flagged in a detailed GDS audit. The other 60 to 70 percent require manual and assistive-technology testing, but if your automated scan is already showing hundreds of issues, you do not need a human auditor to tell you the work needs doing.
   This is where Platform81’s free WCAG 2.2 scanner comes in. Drop in your Trust’s URL and you will get a clear, plain-English readout of where your site sits against the current legal standard, what the top issues are, and how serious each one is. No sign-up, no sales call. Run it on your homepage, run it on your find-a-service page, run it on your most-visited patient landing page. You will have a working picture in under five minutes.
   Scan your Trust website free with Platform81’s WCAG 2.2 scanner →
2. Review your accessibility statement. Pull up your current accessibility statement, usually at /accessibility, and check three things. Does it reference WCAG 2.2 (not 2.1)? Is the last-reviewed date within the last 12 months? Does it list known accessibility issues honestly? If the answer to any of those is no, it needs updating before anything else, because an out-of-date statement is itself a compliance failure and is the single easiest thing for the regulator to flag.
3. Audit your PDFs. Produce a list of every PDF currently linked from your website. Prioritise the ones that patients actually need: forms, consent documents, service information, visitor guides. Plan to either remediate them (add tags, confirm reading order, add alt text to embedded images) or replace them with accessible HTML pages. Board papers and archived reports can usually be handled under the disproportionate burden provisions if the fix cost would genuinely be disproportionate, but that judgement has to be documented in your accessibility statement with reasoning.
4. Commission a human-led audit. Once your automated scan has given you the baseline, a human-led audit by a specialist will surface the 60 to 70 percent of issues automated tools cannot catch. Automated tools don’t use screen readers or navigate via keyboard the way real patients with disabilities do. A human expert bridges the gap between technical code-checking and actual human usability. This is the audit that forms the procurement business case: a document you can take to your board, your exec team, or your IT colleagues to justify the investment needed to reach full compliance.
5. Plan the remediation programme. For most Trusts, full WCAG 2.2 AA compliance is not reachable without some combination of content changes, template changes, and (often) a CMS or design system upgrade. That is a project, not a ticket, typically 4 to 6 months for a full Trust website if scoped properly. The important thing at step five is not to panic, but to get the scope on paper so you can plan the budget, procurement route (Insight UK framework, G-Cloud, or direct award depending on scale) and internal stakeholder engagement.
6. Build accessibility into everything new. The most expensive accessibility work is always retrofitting. Every new service page, campaign microsite, recruitment landing page or staff portal you commission from this point forward should be built to WCAG 2.2 AA from the start. That means briefing your agency properly, requiring evidence of testing, and including accessibility acceptance criteria in your sign-off process. Getting this right on new work is what stops the problem from getting worse while you are fixing the existing estate.
7. Establish ongoing governance. Achieving WCAG 2.2 AA is a project; maintaining it is a process. Websites decay over time as devolved editors across different hospital departments add new content. Set up continuous monitoring, CMS guardrails, and staff training so your site doesn’t slide backwards into non-compliance.

WHERE PLATFORM81 FITS

We have built NHS Trust websites across England, including for Sandwell and West Birmingham NHS Trust, Birmingham and Solihull Mental Health NHS Foundation Trust, Royal Wolverhampton NHS Trust Charity, and Black Country NHS. Every one of those projects was delivered to the accessibility standard in force at the time, and every one of them went through NHS procurement governance. We are an approved supplier on the Insight UK framework. We hold Cyber Essentials Plus, IASME certification, and ISO 9001: the credentials your SIRO and procurement team will ask about on day one.

We also know that launch day is just the beginning. We don’t just build a compliant site and walk away. We provide the robust CMS features, editorial guardrails, and retainer support necessary to empower your comms teams to easily maintain compliance going forward.

We built the free WCAG 2.2 scanner precisely because the single biggest barrier to NHS accessibility work is not capability or budget, it is visibility. Most Trust comms teams simply do not have a clear, up-to-date picture of where their site stands. The scanner closes that gap in under five minutes, and the report it produces is something you can share with your board to justify the conversation about what happens next.

If you want to talk through what the results mean, we offer a free 30-minute discovery call with no hard sell. We can help you interpret the findings, talk through procurement options, and, if it is helpful, scope a remediation or replacement project against the Insight framework so you are working with pre-vetted suppliers on a simplified timeline.

Accessibility compliance in 2026 is not about hitting a ceiling. It is about closing a gap that is widening every month the regulator monitors you and your legacy site stays still. The first step is seeing where you are. The rest becomes considerably easier once you do.

Run your free WCAG 2.2 scan now →

Prefer to talk first? Book a 30-minute call with our NHS team.

Platform81 is an NHS digital specialist with a proven track record of delivering accessible, compliant websites for Trusts across England. We hold Cyber Essentials Plus, IASME certification, and ISO 9001, and are an approved supplier on the Insight UK framework.