Website accessibility for healthcare
Websites Every Patient Can Use, Built to WCAG 2.1 AA
An accessible, conformant website reduces your legal risk and welcomes every patient. We audit, redesign, rebuild and test your site, then document every step.
- Built to WCAG 2.1 Level AA
- Tested by hand and by machine
- Every step documented
Why this matters now
The Deadlines Are Set, and Patients Are Waiting
Patients who use screen readers, keyboards or zoom can't book appointments or find your hours on an inaccessible site. Federal rules and the courts point to the same standard: WCAG 2.1 Level AA.
May 10, 2027
Federal deadline for providers with 15+ employees
The HHS Section 504 rule requires providers that receive HHS federal financial assistance, including Medicare Part B alone, to meet WCAG 2.1 AA.
May 10, 2028
Deadline for providers with fewer than 15
The same HHS Section 504 requirement applies to providers with fewer than 15 employees one year later.
WCAG 2.1 AA
The standard courts point to
In ADA Title III website cases involving private businesses, courts and the Department of Justice regularly point to WCAG 2.1 Level AA.
Source: Reed Smith on the Section 504 dates (opens in a new tab). Confirm your status with your legal counsel.
Which Deadline Applies to You?
Answer two questions. Your date appears on the card beside them.
Choose an answer again to clear it.
Your result
Waiting for your answers
Your date appears here
Answer both questions on the left. Your deadline and the days you have left show up on this card.
- Answer question 1
- Answer question 2
See it the way patients do
One Booking Form, Two Very Different Visits
Choose how a patient uses the web, then switch between a typical practice website and one we rebuilt to WCAG 2.1 AA.
What the screen reader says
- Edit text
- Edit text, invalid entry
- Edit text
- Button
- Click here, link
- Book an Appointment, heading level 2
- Full name, required, edit text
- Phone number, required, invalid entry. Enter a 10‑digit phone number
- Preferred day, edit text
- Request Appointment, button
- Read our accessibility statement, link
What goes wrong
Typical sight
It looks fine at a glance. But the labels are light gray placeholder text that disappears as soon as a patient starts typing.
WCAG success criteria
- 1.4.3 Contrast
- 3.3.2 Labels or Instructions
What we fix
Typical sight
Every field has a visible label above it, and all text meets the 4.5:1 contrast minimum.
WCAG success criteria
- 1.4.3 Contrast
- 3.3.2 Labels or Instructions
What goes wrong
Blurred vision
Small, light gray text blurs into the background. A patient with low vision cannot tell which field is which.
WCAG success criteria
- 1.4.3 Contrast
- 1.4.4 Resize Text
What we fix
Blurred vision
Larger, darker text and clear labels stay readable when vision is blurred. We also test every page at 200% and 400% zoom.
WCAG success criteria
- 1.4.3 Contrast
- 1.4.10 Reflow
What goes wrong
Red-green color blindness
The phone number error is shown only as a red outline. With red-green color blindness, the warning disappears.
WCAG success criteria
- 1.4.1 Use of Color
What we fix
Red-green color blindness
The error is written out in words with an icon, so the message does not depend on color.
WCAG success criteria
- 1.4.1 Use of Color
- 3.3.1 Error Identification
What goes wrong
Keyboard only
Tabbing through the form shows no focus outline, so a patient using a keyboard cannot see where they are.
WCAG success criteria
- 2.4.7 Focus Visible
What we fix
Keyboard only
A thick, high-contrast focus ring shows exactly where the keyboard is, in a logical order.
WCAG success criteria
- 2.4.7 Focus Visible
- 2.4.3 Focus Order
What goes wrong
Screen reader
Without labels, the fields announce only as "edit text" and the icon button just says "button". A blind patient has to guess.
WCAG success criteria
- 1.3.1 Info and Relationships
- 4.1.2 Name, Role, Value
What we fix
Screen reader
Every heading, field, error and button has a name, so the screen reader tells the patient exactly what to do.
WCAG success criteria
- 1.3.1 Info and Relationships
- 4.1.2 Name, Role, Value
Who is this for?
Practices That Want Every Patient to Get In
Owners, practice managers and marketing leads who have heard about ADA website lawsuits or federal deadlines, want to be protected, and want a site that serves patients with disabilities and loads fast.
Plugins and overlays
Why a Widget Isn't Enough
Accessibility widgets sit on top of your site and leave the real problems in the code. In 2025, the FTC finalized an order requiring a major overlay vendor to pay $1 million over claims that its widget made websites compliant.
| What to compare | Widget or overlay | RecommendedOur rebuild |
|---|---|---|
| Fixes the underlying code | Widget or overlay: No. It adds a layer on top of the code that has the problems. | Our rebuild: Yes. We write every heading, button, form and menu ourselves. |
| Works with real screen readers | Widget or overlay: Often not. Blind users and advocacy groups widely criticize overlays. | Our rebuild: Yes. We test with NVDA and VoiceOver, the tools patients use. |
| Documented testing | Widget or overlay: No. There is no report on how your own pages perform. | Our rebuild: Yes. A summary report with manual and automated results. |
| Holds up after updates | Widget or overlay: Not reliably. The widget guesses again on every page load. | Our rebuild: Yes. The fixes live in the code, so a plugin update cannot undo them. |
| Effect on page speed | Widget or overlay: Heavier. It adds a third-party script to every page. | Our rebuild: Lighter. Light pages with little or no extra JavaScript. |
Our process
Six Phases, Each One Signed Off
You always know what we are doing, what you will receive, and what has to happen before we move on.
Phase 1: Audit and remediation playbook
We scan every page with automated tools and test key pages by hand.
Phase 2: Accessible brand guidelines
Our creative director adapts your brand colors and typography so every combination passes contrast requirements, while keeping your look.
Phase 3: Mockup and review
We design your new site with your real content, FAQs and preferences, and refine it with you until you approve it.
Phase 4: Build and test
We rebuild your site from clean code. Then we test it with keyboard-only navigation, real screen readers (NVDA and VoiceOver), 200% and 400% zoom, and automated tools (axe DevTools, WAVE, Lighthouse and PageSpeed Insights).
Phase 5: Accessibility statement
We publish a public statement documenting your standard, the steps taken, and how patients can get help.
Phase 6: Launch and verify
We move your site to your domain, re-test everything on the live site, and update your report.
Each phase ends with your approval or a passed test before the next begins.
Why we rebuild
We Fix the Code Your Patients' Devices Read
Page builders and plugins add code we can't fully control, and many accessibility problems live inside it.
So we rebuild your site with a modern framework, where we write every button, form and menu ourselves.
- Every button, form and menu written by us
- Works with keyboards and screen readers
- Pages that load faster
On WordPress today?
- Your current site stays live while we build.
- We move your pages, posts and images for you.
- Every old address points to its new page with a permanent redirect.
What you get
Every Step, Documented and in Your Hands
Together, the testing report and the accessibility statement are your record of good-faith compliance.
Phase 1Audit
Remediation playbook
What fails today, why it matters to patients, how we fix it.
Phase 2Brand guidelines
Accessible brand guidelines
Colors, type, focus styles and buttons, every pairing checked.
Phase 3Mockup
Approved mockup
Your new design with your real content, signed off by you.
Phase 4Build and test
Testing report
Tools used, before and after results, every fix explained.
Phase 5Statement
Accessibility statement
Your standard, the steps taken, how patients reach you.
Phase 6Launch
Rebuilt website
Clean code that works with keyboards and screen readers.
Post-launch re-test
A full re-test on your live domain.
OptionalOngoing
Monitoring plan
Checks before every update, monthly scans, quarterly hands-on checks, a yearly statement review and a staff guide.
Want to see an audit first? Ask us for a sample audit report.
Built for healthcare
Made for the Way Practices Actually Work
Medical sites lean on vendor tools, forms and maps. We check each one, not just your pages.
Booking tools and portals
Booking tools and patient portals are often run by vendors. We test them early, ask the vendor for its accessibility report, and list any gaps with another way to finish the task.
Intake forms and PDFs
We turn downloadable intake forms into accessible web forms where we can, and provide tagged, accessible PDFs where we cannot.
Every location, by keyboard
Every map comes with a text list of addresses, phone links and directions links, so patients can find you without a mouse.
Forms that respect privacy
We flag any form that invites patients to send health details, so you can decide with your form provider how to handle it.
FAQ
Frequently Asked Questions
It depends on your practice. If you receive HHS federal financial assistance, including Medicare Part B payments alone, the HHS Section 504 rule requires your website to meet WCAG 2.1 AA. The deadline is May 10, 2027 if you have 15 or more employees, and May 10, 2028 if you have fewer than 15.
Separately, in ADA Title III cases involving private businesses, courts and the Department of Justice regularly point to WCAG 2.1 AA. Your legal counsel can confirm what applies to you.
The ADA (Americans with Disabilities Act) is a civil rights law. It requires businesses to serve people with disabilities, but it does not spell out technical rules for websites.
WCAG (Web Content Accessibility Guidelines) is the technical standard, written by the W3C. It breaks accessibility into testable rules at three levels: A, AA and AAA. Level AA is the usual legal benchmark, and it is what we build to.
Plugins and overlay widgets add a layer on top of your site. They do not fix the code underneath, they often conflict with the screen readers patients already use, and they do not prevent lawsuits.
In 2025 the FTC finalized an order requiring a major overlay vendor to pay $1 million and barring it from claiming its product makes any website compliant without evidence. We fix the code itself and test it by hand.
It depends on the size of your site, the third-party tools it uses, and how quickly approvals come back. After your free audit, we give you a timeline in your proposal. Each phase ends with your approval or a passed test before the next one begins. If you have a deadline, tell us up front so we can plan around it.
Yes, it will be cleaner and easier to use, but it will still look like your practice. Our creative director keeps your brand and adjusts colors only where they fail contrast. You see and approve the mockup before we build anything.
No. No one can honestly guarantee that. A site built to WCAG 2.1 Level AA, with documented testing and a public accessibility statement, significantly reduces your legal risk and shows good-faith effort to serve every patient.
We re-test the live site, update your testing report and publish your accessibility statement. Every content update can create new issues, so we also offer an ongoing monitoring plan: automated checks before each update goes live, monthly scans, quarterly hands-on spot checks, a yearly statement review and a one-page guide for your staff.
We are not a law firm. Consult your legal counsel about your specific obligations.
Start before the deadline
The First HHS Deadline Is May 10, 2027. Find Out Where Your Site Stands.
We'll scan your site and send you a summary of the top issues. No obligation.
Until the first HHS deadline
May 10, 2027
The first HHS deadline is May 10, 2027.
May 10, 2027, for providers with 15 or more employees.
Your free audit
- A scan of your site
- A summary of the top issues
- No obligation