HHS Section 504 Website Deadline Now 2027 | El Paso

When the U.S. Department of Health and Human Services pushed the Section 504 website accessibility deadline back a full year in May 2026, there were two ways to take the news. One is relief — the folder marked “website stuff” goes back in the drawer for another twelve months. The other is no reaction at all, because nobody in the office knew there was a deadline in the first place.

Neither one is the right read. The HHS — Health and Human Services — Section 504 website accessibility deadline moved. The rule underneath it did not. If your practice’s website was out of compliance on May 10, 2026, it is still out of compliance today — you just have more runway to fix it before the enforcement date arrives. For a lot of El Paso practices — dental offices, family medicine clinics, physical therapy, behavioral health — that difference is the difference between a fixable problem and an expensive one.

The Date Moved. The Rule Didn’t.

In May 2024, HHS finalized a rule under Section 504 of the Rehabilitation Act requiring recipients of federal financial assistance to make their websites and mobile apps accessible to people with disabilities. The technical standard is the Web Content Accessibility Guidelines — WCAG 2.1, Level AA — written into the Code of Federal Regulations at 45 CFR § 84.84. That rule took effect July 8, 2024. The obligation to not discriminate on the basis of disability in your web services has been live since that day.

What the rule also included was a runway — a future date by which your site had to actually meet the WCAG 2.1 AA standard. Originally that was May 11, 2026 for entities with 15 or more employees, and May 10, 2027 for those with fewer than 15.

On May 11, 2026, HHS published an interim final rule (published in the Federal Register at 91 FR 25496, document 2026-09266) extending both dates by exactly one year:

• 15 or more employees: May 11, 2027
• Fewer than 15 employees: May 10, 2028

Read that carefully. HHS extended compliance dates. It did not repeal the rule, suspend it, or make it optional. The underlying regulatory text — which you can read yourself in 45 CFR Part 84, Subpart I — is unchanged.

The practical translation: an extended deadline is extra time to fix problems that are already problems. It is not a new starting line. A practice that treats May 2027 as “the day this becomes real” is carrying two years of unaddressed obligation behind it and less than a year of runway in front of it.

Does This Actually Apply to My Practice?

The test is simpler than the regulation makes it sound: does your practice receive federal financial assistance?

For most healthcare providers in El Paso, that question resolves to another one — do you bill Medicaid? If yes, you’re a recipient of federal financial assistance, and Section 504 applies to you. That sweeps in a lot of practices that don’t think of themselves as “federally funded”: pediatric dentists, community mental health providers, home health agencies, durable medical equipment suppliers, independent primary care offices, therapy clinics.

Employee count doesn’t determine whether the rule applies. It only determines when your compliance date lands — May 11, 2027 or May 10, 2028.

Now the part almost nobody mentions. Section 504 is not your only exposure. The Americans with Disabilities Act — the ADA — applies to public-accommodation websites separately, right now, with no future deadline attached to it. There’s no grace period there and no phase-in schedule. ADA web accessibility claims usually arrive as demand letters from plaintiff’s firms rather than filed lawsuits — a letter arrives, it cites specific barriers on specific pages, and it proposes a settlement number that’s cheaper than fighting.

So you have two overlapping obligations. One has a date on it. One doesn’t. Practices that fixate on the 2027 date sometimes miss the obligation that has no date on it at all — because that one is already past due.

What WCAG 2.1 AA Actually Means, in Plain Terms

WCAG 2.1 Level AA sounds like a certification you buy. It isn’t. It’s a checklist of design and code behaviors, and most of it is legible to a non-developer once translated:

1. Text has to be readable against its background. There’s an actual math formula for this — a contrast ratio. Normal-size body text needs 4.5:1. Light gray on white fails. So does that muted teal your designer picked for the “Request Appointment” button.

2. Everything has to work with a keyboard alone. Someone who can’t use a mouse navigates by pressing Tab. Every link, button, dropdown, and form field must be reachable that way, in a sensible order, with a visible outline showing where they are. Tab through your own appointment form sometime and watch where the focus disappears.

3. Forms have to announce themselves to a screen reader. A blind patient filling out your new-patient intake hears the page. If a field’s label is only visual placeholder text, or an error message appears in red with no programmatic connection to the field, they get “edit text, blank” and no way to know what went wrong.

4. Video needs captions. That two-minute “meet the doctor” clip on your homepage needs real captions, not auto-generated ones full of mangled medical terms.

5. Color can’t be the only carrier of meaning. “Required fields are marked in red” fails, because a colorblind patient sees no difference. Add an asterisk, add text.

6. Images need alternative text that describes them. Your office photo, your provider headshots, your insurance logos — each needs a text description a screen reader can read aloud. Decorative flourishes get an empty alt attribute on purpose. Content images with an empty alt are a violation, and they replicate across every page that uses them.

None of that is exotic. All of it is invisible on a normal visit to your site, which is exactly why it goes unfixed for years.

Why Your Free Accessibility Scan Says You’re Fine (And Why That’s Not Reassuring)

Somebody runs a free browser-extension accessibility checker on the homepage, gets a green checkmark, screenshots it, and the conversation ends.

I want to show you two things from my own site — not a client’s, mine — that explain why that green checkmark means less than it appears to.

Finding one: the scanner skipped 100% of my homepage content. My site fades sections in as you scroll. Before a section enters the viewport it sits at opacity: 0. Automated checkers skip invisible elements by design, because invisible elements usually don’t matter. So my homepage came back reporting zero problems while seven out of seven sections were never examined at all. Not “passed.” Never looked at. A perfect score on an empty test.

Scroll animations are everywhere on modern healthcare sites. If yours has them, your scanner is very likely reporting on a fraction of what a patient actually sees.

Finding two: no automated tool evaluates hover states. My main call-to-action button — the single most important element on the page — was failing contrast badly at rest, and getting worse when you moved the cursor over it. That was true for months. Every scan I ran came back clean, because no scanner in common use computes contrast for the hover state. I found it by pulling the color values and calculating the ratios by hand. It’s fixed now. But nothing automated was ever going to tell me.

So what does a real check look like? On my own site, it means auditing every page at three screen sizes — desktop, tablet, and phone, because layouts break differently at each — and publishing the result rather than describing it. Current number: 124 pages, 372 page-checks, 0 violations. I’m not putting that up as a trophy. I’m putting it up because “we’re accessible” is a dead phrase and “372 page-checks, zero violations” is a measurable one, and your practice deserves the second kind of answer about its own site.

What to Do Between Now and May 2027

A realistic sequence for a small practice with limited time and no in-house developer:

1. Get a real audit, not a scan. You want a report that names specific pages, specific elements, and the specific WCAG criterion each one fails — with keyboard testing and hover states included. If the deliverable is a PDF from a browser extension, you paid for a screenshot.

2. Fix patient-facing transactions first. Not the homepage. Online scheduling, new-patient intake forms, the patient portal login, contact and directions, insurance information. These are where a barrier stops someone from actually receiving care, and they’re where a demand letter will point first.

3. Do not install an accessibility overlay widget. You’ve seen the pitch: one line of JavaScript, a little wheelchair icon in the corner, instant compliance. They don’t repair anything. An overlay sits on top of broken markup and tries to patch it in the browser, which means the HTML — the underlying code of the page — that a screen reader actually reads is still broken underneath. They frequently conflict with the assistive technology a user has already set up the way they want it. And installing one doesn’t remove your exposure — a demand letter cites specific barriers on specific pages, and a widget that didn’t fix those barriers is not a defense. There is no line of JavaScript that makes an inaccessible site accessible.

4. Fix the underlying code. Contrast ratios in your stylesheet. Real labels on form fields. Semantic HTML for buttons and links. Captions on video. Alt text written by a human who knows what the image shows.

5. Re-audit after every site change. A new page, a new plugin, a redesigned header — any of these can reintroduce violations. Accessibility isn’t a project you finish, it’s a condition you maintain.

6. Bring in a developer when the fix is structural. Writing better alt text is something your office manager can do in an afternoon. Rebuilding a scheduling form so it’s keyboard-navigable and screen-reader-legible is not.

One honest caveat: I’m a web developer, not an attorney. I don’t certify legal compliance and nobody building websites should tell you they do. What I do is build to the WCAG 2.1 AA standard and audit against it, page by page, at three screen sizes, and hand you the numbers.

If you’d rather have someone check your practice’s site against the real standard than guess from a green checkmark, I do manual WCAG 2.1 AA audits for El Paso businesses — including the parts automated tools structurally cannot reach. You’ll get a list of what’s actually failing and what it takes to fix it. No wheelchair icon in the corner.

You have until May 11, 2027, or May 10, 2028. You’ve also had an obligation since July 8, 2024. Both of those things are true at the same time.

Resources

• HHS interim final rule extending compliance dates (91 FR 25496) — the official May 2026 notice moving the dates to 2027 and 2028
• 45 CFR Part 84, Subpart I — the actual regulation text, including the WCAG 2.1 AA standard at § 84.84