Healthcare Web Accessibility: Section 504, ADA Title II, and What Changed in 2026

A patient tries to book a follow-up appointment through your portal. The date picker is a grid of unlabeled divs with click handlers, so their screen reader announces nothing usable. They can't confirm the slot, they miss the visit, and now there's a gap in their care that started with a keyboard trap. That is not a hypothetical. It is one of the most common patterns we find when we scan healthcare front ends, and as of 2024 it is squarely a federal compliance problem in the United States — with deadlines that just moved.

Healthcare has spent years treating web accessibility as a nice-to-have that lives somewhere below HIPAA on the priority list. That framing is now wrong. Two federal rules published in 2024 name your patient portal, your scheduling flow, your intake forms, and your PDF after-visit summaries specifically. Both had compliance deadlines that were extended in 2026, which bought most teams time but did not change the destination. Here is what's actually in scope, what the new dates are, and how to fix the violations where they live.

Two rules, one technical standard

Most healthcare organizations are covered by one or both of these, and they resolve to the same place.

The HHS Section 504 rule is the big one for healthcare. On May 9, 2024, the U.S. Department of Health and Human Services published a final rule under Section 504 of the Rehabilitation Act requiring that web content and mobile apps made available by recipients of HHS funding conform to WCAG 2.1 Level A and Level AA. "Recipients of HHS funding" is broad: most hospitals, physician practices, federally qualified health centers, long-term care facilities, health plans, research institutions, and medical schools take some form of HHS financial assistance, which pulls them in. The scope covers every digital touchpoint of a program — websites, patient portals, mobile apps, and even check-in kiosks.

The ADA Title II rule covers public entities. On April 24, 2024, the Department of Justice published a final rule requiring state and local government web content and mobile apps to conform to WCAG 2.1 Level AA. For healthcare, this catches public hospitals, county health departments, and public university medical centers. Organizations that are both HHS-funded and a public entity — a public teaching hospital, for instance — are covered by both rules and have to satisfy both. We wrote about the Title II rule in more depth in our ADA Title II piece.

The common thread is WCAG 2.1 AA. You do not need to track two separate technical checklists. You need to conform to WCAG (2.1 AA is the floor; 2.2 AA is a superset and a safe target) and be able to produce evidence formatted for whichever regulator is asking.

The deadlines moved in 2026 — here are the real dates

If your last briefing said "May 2026" or "April 2026," that briefing is out of date. Both rules were extended by one year through interim final rules in spring 2026.

For the HHS Section 504 rule, the HHS Office for Civil Rights issued an interim final rule in May 2026 extending compliance to May 11, 2027 for entities with 15 or more employees, and May 10, 2028 for entities with fewer than 15 employees.

For ADA Title II, the Federal Register published an interim final rule on April 20, 2026 extending compliance to April 26, 2027 for state and local government entities serving a population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments.

A public hospital serving a large metro area is therefore looking at April 2027 under Title II and May 2027 under Section 504. Those are close enough that you should plan to the earlier one and be done with both. The extension is not a reprieve; it is a slightly longer runway on a plane that is still taking off.

What actually breaks in healthcare front ends

Healthcare UIs are form-heavy, stateful, and often stitched together from a portal vendor, a scheduling widget, and a decade of internal apps. That is exactly the recipe for accessibility failures. The WebAIM Million 2025 report — an annual automated scan of the top one million home pages — found detectable WCAG failures on 94.8% of pages, averaging 51 errors per page, with low-contrast text alone present on 79.1% of pages. Those are public home pages. The authenticated screens behind a patient login are usually worse, because they ship faster and get tested less.

The patterns we see most often in healthcare products:

• Unlabeled form inputs in intake and scheduling. Date pickers, insurance-ID fields, and symptom checkers built as styled divs with no label or role. A screen reader user cannot complete them.
• Color as the only signal. Red for an overdue lab result, green for normal, with no text or icon. Fails color-blind users and violates the use-of-color and contrast criteria.
• Inaccessible PDF documents. After-visit summaries, lab reports, and consent forms delivered as untagged PDFs. These are explicitly in scope under both rules.
• Focus traps in modals. "Confirm your appointment" dialogs that never move focus, can't be dismissed with a keyboard, or let focus escape behind the overlay.
• Time limits with no extension. Portal sessions that expire mid-form with no warning, which disproportionately hit older patients and those who navigate more slowly.
• Charts and vitals with no text alternative. A blood-pressure trend rendered as an SVG with zero accessible description is invisible to assistive technology.

None of these are exotic. They are ordinary front-end bugs that happen to also be federal compliance failures. If you want the code-level breakdown, our post on common WCAG violations in React and JSX goes deeper, and accessible forms in React covers the intake-form patterns specifically.

Fix it in the codebase, not with a widget

Most healthcare front ends today are React, sitting in front of an EHR or a portal API. That matters, because the two dominant ways to "fix" accessibility are not equal.

Overlay widgets — the JavaScript snippet that promises instant compliance — sit on top of your shipped app and try to patch the DOM at runtime. They don't change the unlabeled date picker in your component; they guess at it on every page load, and they've been named in lawsuits rather than preventing them. We laid out the tradeoffs without the theatrics in overlay widgets vs. source-code fixes. The short version: if the problem is in your JSX, the durable fix is in your JSX.

That's the approach inklu takes. We scan your web app or your repository against WCAG 2.2 using axe-core v4.11 plus more than 50 proprietary rules layered on top, then generate the actual code fix and open it as a GitHub pull request. The fix lands in your component — a real aria-label, a corrected contrast token, a proper <button> instead of a clickable div — so it ships with your next deploy and stays fixed. We support the stack healthcare teams actually use: HTML, CSS, JSX (including TSX), and SCSS. Fixes are generated with OpenAI's GPT-4o, and inklu never trains a model on your code.

A few things that matter specifically for healthcare teams:

• Nothing touches your default branch without consent. Every fix arrives as a pull request you review and merge yourself. Your existing code review, QA, and change-control gates stay in place — which is what a regulated environment needs.
• Your source is ephemeral. Code is purged after each scan; it isn't retained. For an organization that already lives under HIPAA, that's the right default. In full transparency: inklu runs in the US East region only and is not SOC 2 certified, so factor that into your own vendor review.
• It runs in CI. inklu integrates with GitHub Actions, so you can catch regressions on pull requests instead of discovering them in a compliance review. We walked through the setup in accessibility in CI/CD with GitHub Actions. GitLab and CircleCI support are on the roadmap, not shipped today.

Evidence, not just fixes

Passing a scan is half the job. When HHS OCR opens a compliance review, or a health-system procurement team runs a vendor assessment, someone will ask for documentation. inklu generates compliance reports formatted for AODA, ADA Title II, and the EAA, so you have a WCAG 2.2 violation list you can hand over rather than reconstructing one under deadline pressure. Note that a formal VPAT/ACR is on our roadmap, not shipped today — so if a buyer specifically requires a VPAT, plan for that gap.

The honest framing: the deadlines moved to 2027 and 2028, but the work didn't get smaller. A patient portal has hundreds of screens and thousands of components, and remediation at that scale is measured in quarters, not weekends. Starting now against the extended deadline is the difference between a planned engineering effort and a scramble.

If you're a healthcare team trying to scope this, the fastest way to see where you stand is to scan a real flow — your login, your scheduler, your intake form — and look at the actual violations. Book a demo at inklu.io, or email hello@inklu.io and tell us which portal is keeping you up at night. You can also compare how inklu stacks up against other tools on our comparison pages or check the pricing if you already know the shape of what you need.