HHS Section 504 Web Accessibility Rule: A Provider Guide

HHS Section 504 web accessibility is now a practical compliance question for any healthcare organization that receives funding from the U.S. Department of Health and Human Services. This guide explains who is covered, which technical standard applies, what the May 11, 2026 date means and how to check your website, patient portal, mobile app, PDFs and forms. It is general information, not legal advice.

What the HHS Section 504 web accessibility rule requires

Quick answer: The HHS Section 504 rule requires recipients of HHS financial assistance to make their web content and mobile apps accessible to people with disabilities, using WCAG as the technical benchmark. The first compliance date is May 11, 2026. Hospitals, clinics and health plans that take HHS funds should confirm their coverage now.

Who, what and when at a glance

• Who: recipients of HHS financial assistance. That can include hospitals, clinics, physician practices and health-plan operations that receive HHS funds. Confirm your status with counsel.
• What: websites, patient portals and mobile apps must meet WCAG 2.1 Level AA, according to the HHS final rule under Section 504 of the Rehabilitation Act. Check the rule text for exceptions.
• When: the first compliance date is May 11, 2026.

Why coverage depends on funding

The trigger is federal money, not the size of your brand or the number of visitors. A small clinic that accepts HHS funds is in scope, and a large system with a separate non-funded line of business may need to map which services fall under the rule. Our healthcare website accessibility compliance guide covers how to document that scope.

The technical standard: WCAG and what it tests

WCAG is the Web Content Accessibility Guidelines, the W3C standard that defines testable success criteria for accessible web content. According to the W3C, WCAG 2.1 is a W3C Recommendation that applies to content on desktops, laptops, kiosks and mobile devices, and it has three conformance levels: A, AA and AAA.

Level AA is the level to plan around for healthcare organizations. Examples from WCAG 2.1 include:

• Text contrast of at least 4.5:1 (success criterion 1.4.3).
• Text that resizes to 200 percent without loss of content (1.4.4).
• Content that reflows at a 320 CSS pixel width without two-dimensional scrolling (1.4.10).
• Every function operable by keyboard (2.1.1).
• Labels or instructions for form inputs (3.3.2) and described errors (3.3.1).

WCAG 2.2 builds on 2.1, and the W3C encourages use of the most current version when updating policies. If you are planning ahead, see our summary of WCAG 2.2 updates for website owners.

What the May 11, 2026 date means now

May 11, 2026 is the first compliance date under the HHS rule. If you are reading this before that date, you have a short window to inventory digital assets, test them and fix the highest-risk barriers. If the date has passed, treat accessibility as a current obligation and an active remediation project, not a future plan.

Check the rule text for whether a later date applies to your organization, and ask counsel how it affects you. Avoid assuming that a quick fix or a single tool will close every gap. WCAG itself is designed to be testable with a combination of automated testing and human evaluation, so budget for both.

How Section 504 differs from ADA Title II and Title III

The ADA and Section 504 overlap, but they are triggered differently. According to the Department of Justice, its ADA web guidance says Title II covers state and local governments and Title III covers businesses open to the public, including hospitals and medical offices. That guidance is dated March 18, 2022, and the DOJ notes it does not reflect the Title II web requirements published in the Federal Register on April 24, 2024.

For a private hospital that takes HHS funds, both Title III and Section 504 can apply at once. The Section 504 rule is notable because it names a technical benchmark, which makes testing more concrete. Federal agencies follow the separate Section 508 standards for their own sites, explained in our Section 508 compliance guide.

A practical checklist for sites, portals, apps, PDFs and forms

Websites and patient portals

Start with the journeys patients actually use: find a provider, book an appointment, log in, view results, pay a bill. For patient portal accessibility, test these flows with a keyboard only and with a screen reader. Use the WCAG 2.2 quick reference to filter criteria by level and technology.

• Every image has a useful text alternative (1.1.1).
• Prerecorded video has captions and audio description where needed (1.2.2, 1.2.5).
• Focus is always visible and never trapped (2.4.7, 2.1.2).
• Session timeouts warn users and allow extension (2.2.1).

Mobile apps

• The app works in portrait and landscape (1.3.4).
• Multi-finger or path gestures have a single-pointer alternative (2.5.1).
• Buttons and fields expose a name and role to assistive technology (4.1.2).
• Visible labels match accessible names (2.5.3).

PDFs and forms

Intake packets, consent forms and billing statements are web content when you publish them online. Give each form field a label, instructions and clear error messages. For PDFs, confirm headings, reading order and alt text, or offer an accessible HTML version.

Example: a small clinic

A three-provider clinic runs a WordPress site, a third-party booking widget and downloadable intake PDFs. Its first week: test the booking flow by keyboard, fix contrast and missing form labels, and replace scanned PDFs with accessible versions. A tool such as Accessify can speed up common fixes on the site itself, but the third-party booking tool needs a conversation with its vendor.

Example: a hospital system

A hospital system has dozens of subsites, a vendor-built patient portal and two mobile apps. Its needs are different: a central inventory, an owner for each property, procurement language that requires WCAG 2.1 AA, and scheduled manual audits. Automated scanning helps with monitoring, but it cannot replace expert testing of complex portal workflows.

How Accessify and other vendors compare for healthcare support

No single tool makes a healthcare organization compliant. The DOJ’s guidance says automated checkers and overlays can be helpful, but a clean report does not necessarily mean everything is accessible, and pairing them with a manual check gives a better picture. The table below describes fit only; confirm healthcare-specific features, mobile app coverage and current pricing on each vendor’s site.

A hospital system with custom portals and apps will likely need an enterprise platform or audit partner in addition to any widget. A small clinic with a standard website may get far with automated remediation plus a manual review of its booking and form pages.

Action checklist before you act on HHS Section 504 web accessibility

• Confirm with counsel whether you receive HHS financial assistance and which services are in scope.
• Inventory every website, portal, app, PDF library and third-party tool patients use.
• Set WCAG 2.1 Level AA as your internal target, and add it to vendor contracts.
• Run automated scans, then test key patient journeys manually with a keyboard and a screen reader.
• Fix the highest-impact barriers first: forms, login, scheduling and payments.
• Publish an accessibility statement and a way for patients to report problems.
• Re-test after every release and keep dated records.

Frequently Asked Questions

What is Section 504 of the Rehabilitation Act?

Section 504 is a federal civil rights provision that prohibits disability discrimination by recipients of federal financial assistance. For healthcare, the HHS rule applies that principle to digital services, so websites, portals and mobile apps offered by funded organizations must be usable by people with disabilities.

How much does compliance cost?

Cost depends on site size, platforms and how many barriers exist, and the references used for this guide give no standard figure. Automated tools can lower the cost of routine fixes. Accessify lists plans from $19/month, but check the vendor’s site for current pricing and budget separately for audits.

Is an accessibility widget enough for a patient portal?

No. A widget with automated remediation can fix many common issues, but complex portals also need manual testing and fixes in code. The DOJ notes that a clean automated report does not necessarily mean everything is accessible. Treat any widget as one layer of a wider program.

Do PDFs and downloadable forms count?

Yes, you should treat them as part of your digital content. Intake forms, consent documents and statements published online need headings, reading order, text alternatives and labeled fields. If a PDF is hard to fix, offer an accessible HTML version and ask counsel how the rule treats archived or exempt documents.

Which standard should we test against?

Test against WCAG 2.1 Level AA, the benchmark named in the HHS rule. Many teams also check WCAG 2.2 criteria so they are ready for later updates. Confirm the exact standard and any exceptions in the rule text or with legal counsel before you set contract language.

What should we do first?

Confirm whether you are a recipient of HHS financial assistance, then inventory every patient-facing digital property. After that, test your top journeys, such as scheduling, login, forms and payment, by keyboard and screen reader, and fix those barriers before polishing lower-traffic pages.

Want a faster start on the fixes a widget can handle? See how Accessify can support your accessibility work alongside manual testing.