Most healthcare organisations have filed web accessibility under things that apply to government websites. That filing is wrong, and the deadline is closer than the filing suggests.
Two separate rules are in play and they are frequently conflated.
The DOJ rule under ADA Title II covers state and local governments and their instrumentalities. Compliance dates were extended by one year and now sit at 26 April 2027 for entities serving populations of at least 50,000, and 26 April 2028 for smaller entities and special district governments.
The HHS rule under Section 504 is the one that matters here, because it reaches much further. It applies to entities receiving federal HHS funding, public or private. Its dates were also extended by a year, to 11 May 2027 for organisations with 15 or more employees and 11 May 2028 for those with fewer.
Both require conformance with WCAG 2.1 Level AA.
Read the HHS scope again. Public or private, based on federal healthcare funding rather than government status. A private practice, a physician group, a specialty clinic, or a health tech company operating as a recipient can fall inside a rule they assumed was about county websites. Whether a specific organisation is covered is a question for counsel, and it is worth asking now rather than in early 2027.
Worth knowing why the dates moved, because it sets the tone: both agencies extended after concluding that entities would struggle to comply, having underestimated the cost and burden of the original timelines. This is not a regulator looking for scalps. It is a regulator that knows the work is real.
Why healthcare is the hard case
In most sectors accessibility is framed as serving a minority of users. Healthcare inverts that framing, and the inversion is the whole argument.
The population that uses health services most intensively skews older, and skews toward exactly the conditions that affect vision, hearing, dexterity, and cognition. Someone managing a chronic condition is more likely than the general population to have a second condition affecting how they use a screen. A patient recovering from a stroke, a cataract operation, or a hand injury is temporarily in the same position.
That means an inaccessible patient portal is not failing at the edges. It is failing disproportionately among the people with the most clinical need and the most contact with the system.
The adoption data supports it. Patient portal activation is consistently lowest among the very elderly, with one large study across two London teaching hospital systems finding activation of around 24 percent in the oldest age band against around 71 percent among those aged 31 to 40. Nobody would design a product that works for one group at three times the rate of another and call it finished.
Six exclusions
Each of these is a person who cannot complete a task, the technical cause, and what fixes it. None of them are exotic.
1. The patient who cannot see the error
She submits the intake form. Nothing visibly happens. The error is a red outline on a field further up the page, and her screen reader was never told anything changed.
Cause. Validation errors surfaced only visually, with no programmatic association between the message and the field, and no live region announcing the change.
Fix. Errors associated with their inputs, announced on occurrence, and stated in text rather than colour. This is standard form engineering that simply never got done.
2. The patient whose session expires mid-form
He is completing a pre-visit questionnaire slowly, because reading takes him longer than it used to. The session times out. The answers are gone, and there was no warning.
Cause. A fixed timeout inherited from a security requirement, with no extension mechanism and no preservation of entered data.
Fix. Warn before expiry, allow extension, and preserve input. Healthcare has legitimate reasons for session limits, which is exactly why the warning and the save matter rather than the limit going away.
3. The patient who cannot tell which results are abnormal
Her lab results display uses red for out-of-range values. She has a colour vision deficiency, which affects a meaningful share of men in particular, and every row looks the same.
Cause. Colour used as the sole carrier of clinical meaning.
Fix. A second signal always. A label, a symbol, a text flag. This one is a two-line change that nobody makes because the design looked fine to the designer.
4. The patient who cannot reach the booking button
He uses a keyboard rather than a mouse because of a tremor. Tab order jumps from the date picker into the page footer, skipping the confirmation control entirely.
Cause. Custom interactive components built without keyboard support, focus management, or correct roles, usually a div acting as a button.
Fix. Native elements where possible, and correct roles, states, and focus handling where custom components are unavoidable. Date pickers are the single worst offender in healthcare interfaces.
5. The patient using the portal on a phone at 200 percent zoom
She has low vision. At the magnification she needs, the layout breaks, content is cut off horizontally, and the submit button sits outside the viewport.
Cause. Fixed-width layouts and absolute positioning that assume a zoom level.
Fix. Reflow that survives magnification, which modern responsive technique gives you nearly for free if it was considered at all.
6. The patient who cannot understand the question
He reads English as a second language. The intake form asks about his "presenting complaint" and offers a list of conditions in clinical terminology.
Cause. Reading level and terminology, which sit adjacent to formal accessibility standards rather than inside all of them, and which matter enormously in practice.
Fix. Plain language, and translation where the patient population requires it. This is the exclusion most likely to be dismissed as out of scope and most likely to affect volume.
What does not solve this
An overlay widget. The category of script that promises to make a site conformant by adding one line to the page.
The reason it does not work is structural rather than a matter of product quality. Conformance depends on how the page is built: whether a control is a real button, whether an error is programmatically tied to its field, whether focus moves correctly through a flow. A script loaded after the fact cannot reliably know the semantics the developer failed to express, and it cannot fix a control it cannot identify.
The honest position is that accessibility is achieved by build discipline and only approximated by retrofit. Which is also the reason the deadline matters now rather than in 2027: the work is component-level, and component-level work done under time pressure is done badly.
What to do with the time
Four things, in order.
Establish coverage. Ask counsel whether your organisation falls under the HHS rule, the DOJ rule, both, or neither. The answer determines the deadline and it is not obvious from the outside.
Audit the transactional paths first. Not the marketing site. Intake, registration, booking, results, messaging, and billing. Those are the paths where exclusion becomes a clinical access problem rather than an inconvenience, and they are where the rules bite hardest.
Fix the component library, not the pages. Most failures in a healthcare product trace to a handful of shared components: form fields, error handling, date pickers, modals, and tables. Fixing those once fixes them everywhere, and it is the only approach that survives the next feature release. That is frontend development work, and it is where UI and UX design decisions either help or actively fight you.
Test with assistive technology, not only with a scanner. Automated tools catch a useful fraction of issues and miss the ones that matter most, including whether a flow is actually completable. Keyboard-only and screen-reader passes through the six paths above find more in an afternoon than a scanner finds in a month.
Where Woltrio fits
Woltrio builds patient-facing healthcare products and the component foundations underneath them, which is where conformance is won or lost.
In practice the engagements are component-level remediation across a product rather than page-by-page fixes, accessible form and flow patterns for the transactional paths that matter clinically, and building it correctly the first time on new work, which costs very little more and avoids the remediation entirely. Where the product is a portal, that sits alongside patient portal software development, and where it is intake or registration it connects to intake forms software. The wider capability set sits under services.
The framing worth keeping is the one this article opens and closes on. Every organisation building patient-facing software will describe accessibility as a compliance obligation until someone points out that the excluded patient is the elderly one managing three conditions, and then it becomes a product problem. It was always the second thing. The deadline just made it urgent.
Start with a scoped assessment from Woltrio.