Patients use your website on some of their hardest days.
Booking a follow-up, finishing an intake form, reading a lab result, paying a bill. Any of those tasks may be done with a screen reader, a magnifier, or a hand with a tremor. We test them end to end and fix what stops them.
One patient visit crosses five systems you don't fully control
A typical visit touches the main website, a scheduling widget, a patient portal from the EHR vendor, a payment processor, and sometimes a telehealth platform. Each comes from a different vendor with its own accessibility record. Patients don't see the seams. They see one hospital or one practice, and a task they couldn't finish.
We test the journey the way a patient experiences it, across every handoff. When a barrier sits in a vendor's product, we document it with evidence your vendor-management team can send back under the contract. In the meantime, we fix what you do control: the link text that leads into the portal, the instructions around it, and an alternative path that doesn't depend on the broken step.
Where we test first
The HHS rule references WCAG 2.1 Level AA. We test against WCAG 2.2 AA and mark the newer criteria, such as Redundant Entry and Accessible Authentication, so you see both views.
| Journey | What we look for | Who is blocked |
|---|---|---|
| Appointment scheduling | Date and time pickers that work by keyboard and announce open slots; a warning before a held slot expires (SC 2.2.1) | Keyboard, screen reader, and switch users; people who need more time |
| Intake and registration forms | Visible labels, grouped questions, errors tied to fields, and no typing the same information twice (SC 3.3.7, new in 2.2) | Screen reader users; people with cognitive or memory disabilities |
| Patient portal sign-in | Password managers and pasted one-time codes allowed; no puzzle CAPTCHAs (SC 3.3.8, new in 2.2) | People with cognitive disabilities, dyslexia, or limited dexterity |
| Bill pay | Payment fields reachable by keyboard, amounts and due dates read in order, and session timeouts that can be extended | Screen reader and keyboard users |
| Lab results and after-visit summaries | Tagged PDFs with real headings and tables, or an HTML version; charts with a text alternative | Blind and low-vision patients; anyone reading on a phone |
| Telehealth | Named mute, camera, and leave buttons; captions; an announcement when the clinician joins | Deaf and hard-of-hearing patients; screen reader users |
The Section 504 dates after the 2026 extension
HHS extended its web and mobile app compliance dates by one year. The technical standard, WCAG 2.1 Level AA, did not change.
is when HHS published an interim final rule extending its Section 504 web and mobile app compliance dates by one year
U.S. Department of Health and Human Services, Interim Final Rule, 91 FR 25496 (FR Doc. 2026-09266)is the Section 504 web and mobile app compliance date for HHS-funded recipients with 15 or more employees
U.S. Department of Health and Human Services, Interim Final Rule, 91 FR 25496 (FR Doc. 2026-09266)is the Section 504 web and mobile app compliance date for HHS-funded recipients with fewer than 15 employees
U.S. Department of Health and Human Services, Interim Final Rule, 91 FR 25496 (FR Doc. 2026-09266)Rules that reach a health care website
Which rules apply depends on how your organization is funded and organized. This is a planning summary, not legal advice.
| Rule | Who it covers | Standard | Date |
|---|---|---|---|
| Section 504 web and mobile app rule (HHS) | Recipients of HHS federal financial assistance, such as many hospitals, health systems, and clinics | WCAG 2.1 Level AA | May 11, 2027 with 15 or more employees; May 10, 2028 with fewer |
| ADA Title II web and mobile app rule (DOJ) | Public hospitals, county health departments, and state university health systems | WCAG 2.1 Level AA | April 26, 2027 or April 26, 2028, by population |
| ADA Title III | Private practices, clinics, and hospitals as places of public accommodation | No web regulation; settlements and courts usually reference WCAG AA | No set date; claims can arrive at any time |
Tracking scripts on patient-facing pages deserve a second look
Analytics tags, ad pixels, session-replay tools, and chat widgets often load on every page by default, including appointment pages, symptom checkers, and the links into the patient portal. Some of them collect the page address, the search terms a patient typed, or the buttons they pressed. Federal regulators and private plaintiffs have both paid close attention to tracking technology in health care in recent years.
We don't decide whether a data flow is permitted under HIPAA or state law; that belongs to your privacy officer and counsel. What we do is make the facts visible. Our Tag & Script Governance audit lists every third-party script on your patient-facing pages, what each one sends and where, whether it fires before or after consent, and who on your team owns it. Tags tend to outlive the campaigns that needed them, and the inventory is where you find out which ones.
The same scripts cost speed. Every tag adds work for the browser, which slows the moment a patient taps Book appointment on an older phone.
PDFs are part of the patient experience
Intake packets, consent forms, price lists, after-visit summaries, and billing statements often arrive as PDFs. An untagged PDF reads as a blank page or a jumble to a screen reader. The HHS rule covers documents you provide through your website and apps, not just HTML pages, although it includes limited exceptions for some preexisting documents that your counsel should review before you rely on them.
Our Document & PDF Accessibility team tags and checks PDFs against ISO 14289-1:2014 (PDF/UA-1), and helps you decide which documents to fix, which to rebuild as web pages, and which to retire. For anything a patient fills in, a web form is almost always the better choice: it works with autofill, it shows errors next to the field that caused them, and nobody has to print it.
Questions from health care teams
Our patient portal comes from our EHR vendor. Is it still our responsibility?
Usually, yes. The HHS rule reaches web content and mobile apps a recipient provides directly or through contracts and other arrangements, so a vendor-hosted portal is generally in scope; your counsel can confirm how that applies to you. In practice, we test the portal, document barriers with evidence, and help you raise them with the vendor through your contract.
Will you need access to patient data?
No. We test on staging environments, with test patients, or with accounts your team creates for us, and we never need production personal data. If your policies require a business associate agreement for any vendor that touches your systems, tell us on the scoping call and we will work through it with your compliance team.
Should we target WCAG 2.1 or 2.2?
The HHS rule references WCAG 2.1 Level AA, so that is the floor for your compliance date. We recommend building to WCAG 2.2 AA, which adds criteria that matter in health care, such as Accessible Authentication for portal sign-in and Redundant Entry for long intake forms. We report against both.
Our deadline moved. Should we wait?
The extension changed the dates, not the work. Portal, scheduling, and document fixes often depend on vendor release cycles measured in quarters, so the extra year is most useful if you start now. Every date is on our compliance deadlines page.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.