UK Healthcare Website Accessibility 2026. A Study of 300 Sites Against WCAG 2.1 and 2.2 AA

Three regulatory frameworks are relevant to the present audit.

• The European Accessibility Act took effect on 28 June 2025 and extends accessibility obligations to private-sector services for the first time at European Union level. UK organisations that supply goods or services into the EU are subject to its provisions.
• The Equality and Human Rights Commission has indicated that web accessibility falls within its enforcement scope under the Equality Act 2010, which applies to all service providers in the UK, including private healthcare providers.
• The Cabinet Office monitoring team continues to publish compliance reports under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, identifying individual public-sector organisations whose websites do not meet WCAG 2.2 AA.

Healthcare websites are accessed under conditions that differ from those for which most commercial websites are designed and tested. The user base includes patients accessing the site while unwell or while supporting another person who is unwell. Pages are loaded on shared family devices and on older smartphones with limited storage or processing capacity. Network conditions vary widely and include clinic and hospital wifi connections that are configured to throttle bandwidth. The user base for these sites also includes patients with cognitive or visual impairments. Accessibility failures in this context produce direct consequences for care delivery, including patients unable to confirm the location of an appointment, unable to read information about a procedure or unable to complete the actions required to access treatment.

The pages patients are trying to use, the appointment bookings and contact forms, are the most broken pages on the average healthcare website. The marketing copy is in better shape than the routes to care.

The audit was conducted to establish a clear and repeatable accessibility baseline for the UK healthcare sector and to provide individual organisations with a defined reference point for prioritising remediation. The methodology is structured to support repeat assessment at six and twelve months, both at sector level and at the level of individual sites.

The sample for this audit comprised 300 UK healthcare websites drawn from publicly available UK healthcare sector registers. The sample covers four categories of provider.

• NHS trusts and foundation trusts
• General dental practices
• Independent sector healthcare providers
• Optical and other regulated healthcare sites

Each site in the sample was assessed through two separate automated scans. The first scan was a standard Google PageSpeed Insights audit. PageSpeed Insights runs the Lighthouse engine and returns a 0 to 100 accessibility score for each page alongside scores for performance, best practices and SEO. The Lighthouse accessibility score is derived from a curated subset of the axe-core ruleset. PageSpeed Insights is the audit most digital teams adopt as their accessibility benchmark because the score is quick to interpret, the tool is free to run and the output is presented in a format that does not require specialist accessibility knowledge to read.

The second scan was a direct axe-core scan, version 4.10.2, executed through a headless Chromium browser configured to evaluate each page against the full WCAG 2.0, 2.1 and 2.2 A and AA rulesets together with the axe-core best-practice rules. The scan covered the homepage of every site in the sample. It then covered up to three additional pages per site, identified from anchor tags present on the homepage and selected against a fixed pattern of URL fragments including /contact, /about, /book, /appointment, /services, /treatments, /patient and /find-us. This selection allowed the audit to compare the accessibility position of the pages patients use to access care with the marketing pages on which they typically arrive first.

The PageSpeed scan was executed on 15 May 2026 from Google’s own infrastructure. The axe-core scan was executed from a UK IP address. The scanner identified itself in the User-Agent string as the Priority Pixels Accessibility Scanner and applied a 1.5 second delay between requests to the same domain to avoid imposing load on the host servers. 300 sites returned a successful homepage scan and are included in the analysis presented in this report. Additional URLs included in initial data collection were excluded because they were unreachable, were behind firewalls configured to block automated browsers or returned an error response from the host server.

One methodological caveat applies to every figure presented in this report. Research published by WebAIM indicates that automated accessibility tools detect approximately 30 per cent of the issues that a manual WCAG audit conducted by a trained accessibility auditor would identify on the same site. Automated tools reliably catch missing alternative text, low-contrast text, missing form labels, broken heading hierarchies, missing landmarks and inaccessible interactive elements.

Automated tools detect roughly 30% of real WCAG issues. Every score in this report describes the floor, not the ceiling.

Automated tools do not reliably catch cognitive load issues, ambiguous link text, content that is structurally accessible but practically unusable or barriers that emerge only during a keyboard-only or screen-reader journey through a multi-function form. Every figure reported in this study therefore describes the automated baseline. The full number of accessibility issues present on each site in the sample is higher than the figure recorded by the scan.

The central finding of this audit is the difference between the results returned by PageSpeed Insights and the results returned by a direct axe-core scan of the same pages. The two tools share a common ancestor in the axe rule engine. Lighthouse runs a curated and conservative subset of the axe rules. A direct axe-core scan runs the full WCAG 2.1 and 2.2 AA rulesets together with the axe best-practice rules. The effect of the difference in coverage is that PageSpeed scores frequently sit above Google’s passing threshold on sites that contain a substantial number of WCAG failures recorded by axe-core.

A site returning a 92 PageSpeed mobile accessibility score can record eight separate axe-core violations on the same homepage, including failures classified as critical-impact. The PageSpeed score reflects performance against the curated subset of checks executed by Lighthouse. It is not a measure of conformance against the full WCAG 2.2 AA ruleset.

This difference has direct implications for accessibility reporting in the sector. PageSpeed scores are the metric most healthcare digital teams cite in the accessibility statements they are required to publish under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 or under the Equality Act 2010. Both legal frameworks require the statement to describe conformance against WCAG. An organisation that reports a 92 PageSpeed score in its statement and on that basis characterises its site as broadly compliant is reporting against a score that does not measure WCAG conformance directly. The same site under axe-core analysis returns a list of four to eight named WCAG failures with the rule reference and remediation guidance for each failure.

The axe-core scan produced the following set of results on UK healthcare website accessibility, presented by impact severity. Impact is the axe-core classification of the degree to which a given failure affects disabled users. A critical-impact failure blocks access entirely. A serious-impact failure makes access substantially harder. A moderate-impact failure degrades the experience and creates accessibility barriers for specific user groups. A minor-impact failure represents a best-practice issue rather than a barrier to access.

The count of individual broken elements per page provides a more concrete measure of the user experience on the site than the count of distinct violations alone. A single violation type can be repeated across many broken elements on the same page. One missing-alt-text failure on a page containing 200 unlabelled images is recorded as one distinct violation but 200 broken elements. The element count is therefore a closer measure of the number of individual barriers a user encounters on the page.

A small set of failure types accounts for the majority of WCAG violations recorded across the dataset. The ten failures presented below appear most frequently in the 300-site sample. None are obscure, technically difficult to remediate or disproportionately expensive to address. All have been on the WCAG checklist for more than a decade.

Missing landmark structure is the most frequent failure recorded in this audit and has particular significance for users of assistive technology. A landmark is a structural marker on a page that tells assistive technology what each section is for. The standard landmarks include the main content area, the navigation, the footer and the search region. Without landmarks, screen reader users must read or skip through the entire page sequentially to locate the content they came to find. A page that does not define a main landmark is functionally inaccessible for users who navigate by landmark. 75.7 per cent of the homepages tested in this audit do not contain a valid landmark structure.

The breakdown of results by provider type documents a substantial difference in accessibility position between the public and private healthcare sectors. Private dental practices recorded higher violation counts than NHS Trusts on every measure captured by the audit.

Dental practice homepages produced a mean broken-element count approximately five times that of NHS Trust homepages. The pattern is consistent across the three measures presented above. Dental practice sites recorded higher mean violations per homepage, higher mean broken elements per homepage and a higher percentage of homepages containing a critical or serious failure than the NHS Trust sub-sample.

Private dental practices average five times more broken elements per homepage than NHS Trusts. The sector under no routine regulatory monitoring is also the sector failing patients hardest.

The legal position does not soften this finding for the private sector. NHS Trusts are bound by the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, which require conformance with WCAG 2.2 AA and the publication of an accessibility statement, monitored by the Cabinet Office. Private dental practices fall under the Equality Act 2010, which requires service providers to make reasonable adjustments for disabled users. The Equality Act route is enforced through individual claims and through the Equality and Human Rights Commission rather than through routine government monitoring. The absence of routine monitoring is one plausible explanation for the position of the private sector recorded in this audit. The absence of monitoring does not provide a defence against an Equality Act claim. A patient unable to use a dental practice website as a result of an accessibility barrier has grounds to bring a claim for failure to make reasonable adjustments.

Independent healthcare providers fall between the two regimes and may face exposure under both. Where an independent provider delivers services on behalf of the NHS under a contracted arrangement, the contracting authority can extend Public Sector Bodies Accessibility Regulations obligations to the provider through the terms of the contract.

The deeper scan covered up to three additional pages per site beyond the homepage, identified from anchor tags on the homepage and selected against the URL fragment pattern set out in the methodology. The pattern recorded across these additional pages documents a structural finding. The pages patients use to access care recorded higher violation counts than the marketing pages on the same sites.

Booking and appointment pages recorded the highest mean violation count of any page category in the dataset. Contact pages recorded the highest mean broken-element count of any category. The pages through which patients book appointments, ask questions or contact clinicians recorded higher violation counts and higher broken-element counts than the marketing pages on the same sites.

The likely cause of this pattern is structural. Homepages receive the majority of design and engineering attention because they are the most-visited page in any site’s analytics. They are typically built from custom code produced by the agency responsible for the original delivery. Booking functionality is frequently delivered through an embedded third-party widget fitted into a wrapper template on the host site. The widget vendor treats accessibility as the responsibility of the host site. The host site treats accessibility as the responsibility of the widget vendor. Accessibility for the booking journey is not consistently owned by any party in the arrangement. The patient experiences the cumulative effect.

Accessibility and performance are distinct measurement domains but they overlap in practice. A site that takes ten seconds to render on a mid-tier phone is not usable for a patient in pain, for a patient with a cognitive impairment or for a patient on a constrained network connection in a hospital waiting room. The PageSpeed performance results document a sector performing below Google’s published thresholds across every Core Web Vitals metric.

32 per cent of UK healthcare sites scored below 50 for mobile performance, the threshold Lighthouse classifies as poor. The median time for a patient on a mid-tier phone to see the main content of a healthcare homepage was 8.82 seconds against Google’s recommended threshold of 2.5 seconds.

On a mid-range phone, a patient hitting a UK healthcare homepage waits a median of 8.5 seconds for the main content to load. Google’s recommended threshold is 2.5 seconds.

Industry research published by Google and others documents a sharp decline in completed page interactions as time-to-content rises above the two-to-three-second range. The performance figures recorded in this sample suggest that a substantial proportion of attempted visits to UK healthcare sites do not complete.

Regional variation across the dataset is less pronounced than variation by provider type. A small number of patterns are nonetheless visible in the regional breakdown.

Where regional gaps appear in the data, they tend to track investment cycles in NHS trust digital teams rather than any geographic factor. Regions in which trust digital functions have been consolidated or in which a shared web platform has recently been procured tend to score higher and more consistently across their constituent sites.

The pattern of failures recorded across every provider type in the sample is consistent. Sites that record violations do so not because the underlying accessibility issues are unknown or technically complex but because the issues sit in components that have not been revisited since the site was first built. The original delivery was often handled by a previous agency, and the site frequently runs on a content management system that has moved through several major version updates without a corresponding accessibility review.

The contributing factors that recur most often in the healthcare context are listed below.

• WordPress themes built four to seven years before the audit that pre-date current WCAG 2.2 guidance and have not been audited against the standard at any point since deployment
• Patient portals and booking systems embedded as iframes from third-party providers, where the embedded component scores poorly against WCAG in its own right and falls outside the scope of the host site’s accessibility statement
• PDF documents including clinic timetables, leaflets and reports, uploaded to the site without optical character recognition, structural tagging or alternative text, often as a replacement for content previously rendered as HTML
• Carousel and accordion components built on JavaScript-only interaction patterns that have lost keyboard accessibility following a plugin or theme update
• Content uploaded by clinical teams through the visual editor with no prompts to supply alternative text and no editorial review step before publication
• Form plugins updated for GDPR consent requirements but not updated for accessibility, with required-field indicators that rely on colour alone

None of these factors are new. They persist because accessibility ownership is not formally assigned inside the organisation. The in-house digital team is typically committed to higher-priority safety-related systems. The agency responsible for the original build is no longer engaged on the site. The result is that accessibility debt accumulates over a multi-year horizon before a triggering event prompts a remediation cycle. The most common triggering events are complaints from patients or representative bodies, regulatory communications from the Cabinet Office or the Equality and Human Rights Commission and legal claims brought under the Equality Act.

The first step in any remediation programme is to separate issues that can be addressed at the template level from issues that must be addressed page by page. The axe-core data captured in this audit is dominated by the first category. Six of the ten most common violation types are theme-level issues. A single round of fixes against the template removes these failures from every page on the site at once. A single sprint of theme-level work is typically sufficient to move the average healthcare website from a position characterised by critical or serious failures to a position that meets the automated baseline.

A four-stage programme is recommended for NHS trusts and other public-sector bodies.

1. Establish a baseline. Conduct an automated accessibility audit across every page of the site rather than the homepage alone. Tools such as axe DevTools, Lighthouse CI and WAVE produce a per-page failure list suitable for this purpose. Manual auditing of the top twenty pages by traffic should follow, together with manual auditing of every form and every patient-facing journey on the site.
2. Remediate at the template level first. The header, footer, navigation, card components, form patterns and any embedded patient portals account for the majority of the issues recorded across most healthcare sites. A single round of template-level fixes typically reduces the per-page issue count by 60 to 80 per cent.
3. Update the accessibility statement to reflect the current position. The Public Sector Bodies regulations require a statement that lists what fails, why it fails and when each gap is expected to be addressed. Statements that overstate compliance create greater legal exposure than statements that record known gaps alongside a documented remediation timeline.
4. Embed accessibility into the publishing workflow. The majority of accessibility debt accumulates through ongoing publishing activity rather than during the initial build of the site. Author training, alternative-text prompts at the point of upload in the CMS, automated checks on save and a review step before content goes live each reduce the rate at which new issues enter the site.

The same four stages apply to private providers. The additional consideration for the private sector is that an accurate accessibility statement constitutes a defensible position under the Equality Act in the event that a reasonable adjustments claim is brought against the organisation. A statement that documents known issues alongside a plan and a timeline is treated differently in proceedings from a statement that says nothing or that overstates the position of the site.

The cost of remediating the typical healthcare website is lower than many digital teams expect. Where the underlying content management system is current and the theme is well constructed, the remediation work fits within a single sprint. Where the content management system is older or the site has been heavily customised, the cost rises but remains measured in weeks rather than months. The cost of not remediating is harder to quantify but takes concrete forms. These include a patient unable to locate a clinic, a screen reader user unable to read a discharge summary, a regulatory communication from a monitoring body, a public listing on the GOV.UK monitoring report or an Equality Act claim brought by a patient denied access.

UK healthcare websites are not meeting the foundational requirements of WCAG conformance at a scale that the headline PageSpeed scores do not surface. One in fifteen of the sites tested returned a clean homepage. Three in four contain at least one failure classified as critical or serious enough to prevent patients from using the page. Private dental practices recorded higher violation counts than NHS Trusts. The pages patients use to book and contact care recorded higher violation counts than the marketing pages on the same sites.

The issues driving these failures are neither unknown nor technically complex. They sit in templates, components and content workflows that have drifted, in many cases for years, without a corresponding accessibility review. The same pattern of failures recurs across the sector. The same pattern of remediation therefore applies across the sector. A six-week template-level remediation programme, followed by an updated accessibility statement and embedded checks in the publishing workflow, moves most healthcare organisations from a failing position to a passing position on the automated baseline.

Fewer than seven in every hundred UK healthcare homepages pass an automated WCAG check. Three in four contain failures critical or serious enough to actively block patients from completing the task the page exists to deliver.

The position described in this report is the lower bound rather than the upper bound. The automated tools used in this audit detect approximately 30 per cent of the issues that a manual WCAG audit would identify. Every site in this report carries more issues than were recorded by the scan. The same audit will be repeated at six and twelve months. Where the sector position moves, the subsequent report will document the change. Where the sector position does not move, the subsequent report will record the same headline figures.

The table below lists every site assessed in this audit. The full underlying dataset, including the individual failed audit records per site, is available on request in CSV or JSON form.

How to read this table.

• Accessibility score: Google Lighthouse score from 0 to 100. A score of 90 or above is the threshold Google designates as a passing automated score. Higher is better.
• Performance score: Google Lighthouse score from 0 to 100 covering page load speed and responsiveness. A score of 90 or above is classed as good. A score of 50 to 89 is classed as needs improvement. A score below 50 is classed as poor. Higher is better.
• WCAG violations (homepage): The number of distinct accessibility rule failures the axe-core deep scan recorded on the site’s homepage. Zero indicates that the homepage passed every automated WCAG check executed by the scanner. Lower is better. A dash indicates that the homepage could not be scanned because of a timeout, a block at the host level or an unreachable response. The notation n/a indicates that a Lighthouse score could not be returned for the site.

All scores describe the mobile experience. The mobile experience scores lower than desktop across the dataset and is the experience patients are most likely to be using when they need a healthcare website.