By Mehdi HassanWhat accessibility standard should a healthcare website meet?
A healthcare website should meet WCAG 2.1 Level AA. It's the standard named in HHS's updated Section 504 rule for organizations that receive HHS federal financial assistance, and in the Department of Justice's ADA Title II rule for state and local government entities, which include public hospitals and clinics. Private providers fall under ADA Title III, where WCAG 2.1 AA is the benchmark commonly used in audits and settlements.
This checklist is part of our healthtech website design series. For the general picture across industries, see website accessibility for startups. The legal points here are a summary, so confirm your obligations and current compliance dates with counsel, HHS and ADA.gov.
Rule | Who it covers | Standard |
|---|---|---|
Section 504 (HHS rule) | Recipients of HHS federal financial assistance | WCAG 2.1 AA, with phased compliance dates |
Section 1557 (ACA) | Health programs receiving federal funding, and more | Accessible ICT; language access notices |
ADA Title II | State and local government, including public hospitals | WCAG 2.1 AA under the DOJ rule |
ADA Title III | Private providers open to the public | No set technical standard; WCAG 2.1 AA in practice |
State laws | Varies by state | Often reference WCAG |
Why does healthcare website accessibility matter more than in other industries?
Healthcare website accessibility matters more because the people who most need health services are disproportionately likely to have a disability, and because a failure blocks access to care rather than to a product. A patient who can't complete an intake form with a screen reader, or read a discharge PDF with magnification, may miss treatment.
The legal duties reflect that. Many digital health startups sell to health systems and payers that receive federal funding, so their buyers increasingly ask for accessibility evidence during procurement. Even if your company isn't directly covered, your customers may need you to be.
What does a healthcare website accessibility audit check?
A healthcare website accessibility audit checks every page template and every patient task against WCAG 2.1 AA, using both automated tools and manual testing. Automated scanners catch only part of the problems, so keyboard and screen reader testing is essential. Work through this order.
- Patient tasks end to end. Find a provider, check eligibility, book an appointment, complete intake and pay a bill, using only a keyboard and then a screen reader.
- Forms. Every field has a visible label, errors are described in text, required fields are marked and time limits can be extended.
- Color and contrast. Text and interface elements pass AA contrast, and no status or instruction relies on color alone.
- Headings and structure. One H1 per page, logical heading order and landmarks, so screen reader users can jump through long service pages.
- Images and icons. Meaningful images have alt text; decorative ones are hidden from assistive technology.
- Video and audio. Captions on all video, transcripts for audio and controls that work by keyboard.
- Documents. Patient forms, notices and price lists in PDF are tagged and readable, or published as HTML instead.
- Third-party widgets. Booking, chat, payment and map tools tested like your own pages.
- Zoom and reflow. Pages work at 200% zoom and on narrow screens without losing content.
Which healthcare-specific accessibility checks do teams miss?
The healthcare-specific checks teams miss most are PDFs, session timeouts, language access and embedded tools. These sit outside the page templates designers usually focus on.
- Downloadable patient forms. Many clinics still publish intake and consent forms as scanned PDFs, which screen readers can't read. Offer an accessible online form through a HIPAA-eligible vendor; our guide to HIPAA compliant forms covers the options.
- Session timeouts in portals and intake that log people out without warning. Warn before timing out and let users extend.
- Language access. Section 1557 includes notices about language assistance, and accessible translated content matters for patients with limited English.
- Maps and locators. A location map needs a text list of addresses, hours and phone numbers alongside it.
- Emergency information. Crisis and emergency notices must be reachable and readable by assistive technology, not buried in an image.
Hypothetical example: auditing a clinic's booking flow
For example, suppose a multi-location clinic audits its booking path. The page templates pass most checks, but the embedded scheduling widget traps keyboard focus inside a date picker, announces times as unlabeled buttons and shows available slots only in green.
The fix has two parts. The site team adds a text alternative path (call or request a callback) beside the widget and labels the surrounding content. The clinic asks the scheduling vendor for its accessibility conformance report and a fix timeline, and compares alternatives if the vendor can't commit. The website can be clean and the patient still blocked, so the widget counts.
How should you handle third-party tools on an accessible medical website?
Handle third-party tools by testing them like your own pages and asking vendors for an accessibility conformance report, often based on a VPAT. To a patient, the booking widget is your website. If it fails, the experience fails, whoever wrote the code.
Put accessibility requirements into vendor selection, keep a list of every embedded tool with its conformance status and offer an alternative path (phone, callback request or accessible form) wherever a widget falls short. Our guide to ADA website compliance covers how US businesses approach this more broadly.
How do you keep a healthcare website accessible after launch?
Keep a healthcare website accessible by building accessibility into publishing, not just the launch. Most regressions come from new content: an image without alt text, a new PDF, a video without captions or a widget added for a campaign.
Lock it into components
Build accessible components and CMS fields, such as required alt text, so editors can't easily publish inaccessible content.
Write an editor checklist
A one-page list for anyone who publishes: headings, alt text, link text, captions and PDF rules.
Scan automatically
Run automated checks on every deploy to catch obvious regressions early.
Test manually on a schedule
Repeat keyboard and screen reader tests on key patient tasks each quarter and after major changes.
Publish an accessibility statement
State your target, known issues and how patients can get help or report a problem.
If you need an outside review first, our guide to accessibility audit cost explains what drives the price. Similar duties apply to schools, which our edtech website compliance guide covers. Read the full WCAG standard from the W3C when you need the exact success criteria.
