What does accessibility require on a healthcare site?

# What does accessibility require on a healthcare site?

WCAG 2.2 at level AA, checked automatically on every change and by hand on the pages patients actually use, with an accessibility statement that says so and gives people a way to tell you when something fails. That is the whole requirement. It is not a feature for a later phase, because healthcare is the sector where web accessibility suits are filed most often, and because a patient who can't get through your appointment form with a screen reader has been turned away at the door.

This chapter is the other half of the compliance conversation. Chapter 5 covered what the site is allowed to collect; this one covers who is able to use it.

Why is the bar higher for a healthcare site?

Because the law treats a clinic's website as part of the clinic, and because the people most likely to need an accessible page are the people most likely to be looking for care.

The Americans with Disabilities Act names healthcare providers as public accommodations, and courts have treated their websites as covered for years. Web accessibility suits in the US run to thousands a year, and healthcare is consistently among the sectors named most, partly because the suits are cheap to file and a site is easy to test from a plaintiff's laptop. Two 2024 rules turned the informal standard into a written one: the Department of Justice set WCAG 2.1 AA for state and local government sites, and the Department of Health and Human Services set the same level under Section 504 for organisations that receive HHS funding, which includes most providers that bill Medicare or Medicaid, with compliance dates in 2026 and 2027. Ask counsel which of these applies to you. Build to 2.2 AA and the answer doesn't change what you build.

The practical reason is simpler. Patients with low vision, patients with a tremor, older patients, a parent on a phone with one free hand: the same page has to work for all of them. Accessible design and design for a visitor in a hurry turn out to be the same design.

What does WCAG 2.2 AA actually ask for?

Eight things, on a marketing site. The full guideline is longer; this is the part that applies to pages, forms, and images.

• Contrast. Text at 4.5:1 against its background, 3:1 for large text and for controls. The starter's design tokens carry the ratio for every colour pair, and links use a darker accent than buttons so that accent-as-text reaches 10.5:1.
• Keyboard. Everything the mouse can do, the keyboard can do, and the focused element is always visible. One focus ring, three pixels, on everything, everywhere. No element traps focus.
• Images. Every image has alternative text or is marked decorative. In the starter, alt is a required field in the schema and a required prop on the image component, so an image without it can't be published or rendered.
• Headings. One H1, then levels in order, describing the content and not the styling. The starter's heading component takes a level and enforces it.
• Forms. Labels tied to their fields, instructions before the field, and errors that name the field and say what to do, in text, announced to assistive technology.
• Targets. WCAG 2.2 added a minimum of 24 pixels for anything you tap. The starter uses 44, which is what fingers actually need.
• Motion and zoom. Animation stops when the operating system's reduced-motion setting is on. Text scales to 200 percent without anything overlapping or disappearing.
• Structure. A skip link as the first focusable element, page landmarks, and a page title that says which page it is.

None of these is hard on a new build. All of them are hard to retrofit into a WordPress theme that somebody else wrote, which is why accessibility is one of the eight lines in the migrate-or-remediate rubric in chapter 1.

What does an automated check catch, and what doesn't it?

Roughly a third of the criteria, reliably, and none of the ones that need a person to judge meaning.

axe, the checker the starter runs in CI, is good at contrast, missing labels, missing alt attributes, ARIA used wrongly, heading order, duplicate ids, empty links and buttons, and a page with no declared language. It finds these every time, in seconds, on every change.

It does not find alt text that exists but is useless ("image.jpg", "doctor"). It does not notice a focus order that jumps from the header to the footer and back. It sees a consent dialog; it does not try to dismiss it from the keyboard. It can't tell that a chart's meaning is carried by colour alone, that the reading order of a two-column layout is wrong, that a video has no captions, that an error message says "invalid" with no instruction, or that the PDF linked from the services page is a scanned image. Those are the failures patients actually hit.

So the automated check is the floor. It stops the site regressing on the things it can see. It does not tell you the site is accessible.

Which manual checks matter?

Five, about an hour, on four pages: the home page, a provider page, a location page, and the contact form.

• Unplug the mouse. Tab through the navigation, open and close the mobile menu, dismiss the consent dialog, submit the form. Focus is visible at every step and goes where you'd expect. If you ever lose track of where focus is, that's a failure.
• Read one provider page with a screen reader. VoiceOver is built into every Mac; NVDA is free on Windows. Does the page make sense read aloud? Can you jump between headings? Does the photo's alt text say something a patient would want to know? Does the booking link say where it goes, or just "click here"?
• Break the form on purpose. Submit it empty, then with a malformed email. The error is announced, names the field, tells you what to fix, and focus moves to it.
• Zoom to 200 percent, then turn on reduced motion. Nothing overlaps, nothing is cut off, nothing still animates.
• Turn off styles, or open reader mode. The order of the content still makes sense without the layout.

Write down what you find. That list is the "known limitations" section of the statement, and it's the backlog.

How do you keep it accessible after launch?

By making the checks part of every change and the guardrails part of the content model, because a site is accessible on launch day and drifts from there.

The starter runs a Playwright smoke test with axe on the home page, a provider page, and the contact form on every pull request, and fails the build on any violation against WCAG 2.0, 2.1, and 2.2 at A and AA. Lighthouse runs alongside it with an accessibility score under 95 treated as an error, not a warning. Neither takes a developer's attention; they run on the change and block it if it regresses.

The larger risk after launch is editorial, not technical. Images pasted without alt text, headings chosen for their size rather than their level, a PDF uploaded where a page should be. The content model is where that gets caught: alt required on every image, a heading component that only offers the right levels, no raw HTML field, and a line in the editor's guide that says why. Chapter 3 covers the model; this is one of the reasons it's shaped the way it is.

Then the statement gets reviewed once a year and whenever the site changes shape. Its known-limitations section should get shorter.

What goes in the accessibility statement?

Five things, in plain language, on a dated page in the CMS where counsel can edit it.

• The standard. WCAG 2.2 at level AA, named.
• How it's checked. Automated checks on every change, manual checks on the pages that matter.
• Known limitations, honestly. Older PDFs is the usual one. Say what they are, what you're doing about them, and how to get the content another way.
• How to tell you. A phone number and an email address that a person reads, and a response time you'll actually meet. Three business days is reasonable.
• The clinics themselves. Step-free access, accessible restrooms, interpreter services including American Sign Language. The web page is where patients look for that before they visit.

The starter seeds a statement with this shape as one of its four legal pages, with a banner that says to replace it before launch.

Two things the statement is not. It is not a badge from an overlay vendor: the widgets that add an accessibility menu to a page do not fix the underlying markup, they're now named in a growing share of the suits, and axe flags some of them. And it is not a promise of perfection. An honest statement with a working contact does more for you in a complaint than either.

Checklist

Companion code in the Healthcare Sanity Starter: e2e/smoke.spec.ts (the axe check that runs on every change), lighthouserc.json (the score budget), docs/DESIGN.md (contrast ratios for every token), and the seeded accessibility statement in scripts/seed/content.ts.