WCAG 2.2 AA Healthcare Website Accessibility: The Complete Guide for 2026

Healthcare organisations tend to assume accessibility failures are a marketing website problem. In practice, the most damaging failures sit inside the patient portal, the booking flow, and the intake form, exactly where a patient cannot simply leave and use a competitor's site.

The average healthcare web page carries 272 accessibility issues, based on a scan of over 65,000 pages across 1,508 healthcare websites by AudioEye. That number reflects real barriers patients encounter every day:

What the data does not show is severity. A missing alt text on a decorative icon is a minor fix. A missing label on a "confirm appointment" button can prevent a patient from booking care at all.

During healthcare implementations, we consistently see 2 failure points repeat across otherwise well designed sites: colour contrast on clinical data and inaccessible multi step forms. Vitals dashboards, lab result tables, and medication lists often use light grey text or colour coded status indicators with no text equivalent. A patient with low vision or colour blindness cannot always distinguish a normal result from an abnormal one, which is a clinical safety issue disguised as a design choice.

Framing this as a UX problem understates the risk. When a patient with a motor disability cannot complete an online intake form, the usual outcomes are:

Each outcome reduces the patient's independence, which is the exact harm ADA Title III, PSBAR, and the Equality Act 2010 are designed to prevent.

WCAG 2.2 AA is built around 4 principles known as POUR. Each principle translates into specific, testable behaviour on a healthcare website rather than abstract design guidance.

Healthcare web pages average 69.1 unique colour contrast violations and 4.0 inaccessible forms per page, according to AudioEye's 2025 industry data. In practice, this means sufficient contrast ratios on clinical text, alt text on every meaningful image, and captions on pre visit instructional video.

Healthcare web pages average 6.1 keyboard accessibility violations per page. In our experience reviewing booking flows, the calendar widget is the single most common keyboard trap on a healthcare site, often because it was built with a third party plugin never tested against WCAG.

A form that rejects an entry with only a red border and no text explanation fails this principle outright. Clinical terminology should be supported with plain language explanations, particularly on intake forms where a misunderstood field can lead to inaccurate medical history.

This principle is where EHR connected pages most often fail, because dynamically loaded content, such as a lab result that appears after an API call, is frequently invisible to screen readers unless ARIA live regions are implemented correctly.

WCAG 2.2 added 9 new success criteria on top of WCAG 2.1, and 5 of them have direct implications for patient facing platforms. One common issue we see is teams assuming a WCAG 2.1 AA audit already covers these, when it does not.

More than 5,000 digital accessibility lawsuits were filed under ADA Title III in 2025, a 37% year over year increase, according to UsableNet's litigation tracking. That trend has expanded beyond retail into healthcare, financial services, and hospitality, which changes how legal teams are prioritising accessibility work.

The HHS Section 504 Final Rule originally set a compliance deadline of May 11, 2026 for organisations with 15 or more employees. On May 7, 2026, HHS issued an Interim Final Rule extending that deadline by 1 year, to May 11, 2027, with a further deadline of May 10, 2028 for organisations with fewer than 15 employees. The extension changes the date, not the underlying obligation:

The same build process that delivers HIPAA-compliant website development also incorporates WCAG 2.2 AA from the first sprint.

UK public sector bodies must meet WCAG 2.2 AA under the Public Sector Bodies Accessibility Regulations 2018, commonly known as PSBAR, and must publish an accessibility statement confirming conformance status. Private healthcare providers fall under the Equality Act 2010, which prohibits discrimination against disabled patients through inaccessible digital services. Where a private provider delivers services to an NHS commissioner, NHS Digital Service Standard obligations typically apply as well. Our NHS-compliant website design process includes WCAG 2.2 AA as a baseline requirement, not an optional add on.

NHS trusts carry a direct, regulator enforceable duty under PSBAR, including a route for complaints to escalate to the Equality and Human Rights Commission. Private providers are held to the broader Equality Act 2010, where accessibility is argued through reasonable adjustment rather than a named technical regulation. In practice, this means private providers face more legal ambiguity, not less risk.

Static marketing pages are usually the easiest part of a healthcare website to remediate. The highest risk, and the highest cost to fix late, sits inside authenticated, dynamic surfaces.

Patient portals combine dynamic content, third party integrations, and complex forms, which creates far more opportunities for accessibility failure than a static page. Across recent compliance projects, we have found that portals built on legacy EHR vendor widgets are the most difficult to remediate, since the component code often sits outside the organisation's direct control. Our approach to accessible patient portal development starts at the architecture stage, before a vendor widget becomes a fixed dependency.

A keyboard trap occurs when a user can tab into a component, such as a calendar date picker, but cannot tab back out using standard keyboard commands. This is one of the most severe issues found in healthcare booking flows, because it can fully block appointment scheduling for a keyboard only user.

Clinical data displays frequently use colour alone to indicate status, such as red text for an abnormal lab value with no accompanying icon or label. This fails WCAG 2.2 AA and creates a genuine safety gap, since a patient who cannot perceive the colour difference may miss a result that needs attention.

Content that loads after the initial page render, such as an appointment confirmation, needs an ARIA live region to be announced to screen reader users. In our work building the Herexa Health telehealth platform, we integrated WCAG 2.2 AA testing at the design stage, which prevented 3 identified keyboard navigation issues from reaching the build phase.

Automated testing tools reliably detect approximately 30% of accessibility issues on a typical page, which means the majority of real barriers require manual verification. This gap is the single most common reason organisations believe they are compliant when they are not.

Automated scanners are strong at detecting:

These checks are objective and rule based, which makes them a reasonable first pass before manual review begins.

Manual testing is required to evaluate logical reading order, whether complex form error messages are announced correctly, and whether ARIA attributes have been applied correctly rather than simply present. One common issue we see is ARIA misuse, where labels are added to satisfy a scanner without confirming they help a real screen reader user.

A complete audit combines automated scanning for baseline coverage, manual keyboard and screen reader testing across JAWS, NVDA, and VoiceOver, and structured review against each WCAG 2.2 success criterion. Our IPPF multi site platform for 5 member organisations required WCAG 2.2 AA compliance across multilingual content, including RTL language support, tested across all 3 assistive technologies on every deployed site.

Accessibility compliant healthcare websites experience 19% higher patient engagement compared to non compliant sites, based on WebAIM's business case research. That figure reframes WCAG 2.2 AA from a compliance cost into a measurable driver of patient interaction. If you want to see the wider business case, read our analysis of how accessibility drives patient acquisition.

Based on our healthcare IT experience, remediating an existing site after launch consistently costs more and takes longer than building to WCAG 2.2 AA from the first sprint. Retrofitting accessibility into an already built component library requires re-testing every dependent page, which building it in from the start avoids entirely.

A structured implementation process typically follows 5 stages:

Priority checklist for remediation:

A single audit only confirms compliance at the moment it was performed. Every new feature, third party script, or content update introduces the possibility of a new violation, which is why ongoing monitoring, not a 1 time certificate, is what actually sustains WCAG 2.2 AA conformance over time.