Healthcare Website Accessibility: ADA, WCAG and Why It Matters
A retired teacher with low vision wants to book a dermatology appointment online. She uses a screen reader, the software that reads a web page aloud, because she can no longer make out small text. She reaches the practice’s booking form and hits a wall: the fields have no labels the screen reader can announce, so she hears “edit text, edit text, edit text” with no idea what goes where. The date picker is a mouse-only widget she cannot operate with a keyboard. She gives up and calls the office, adding a phone call the practice has to staff and a patient who now associates the brand with frustration. Multiply that by every patient using assistive technology, and the cost of an inaccessible site stops being abstract.
Healthcare has a sharper accessibility obligation than most industries, both because its patients skew older and more likely to have disabilities, and because the legal exposure is real. Accessibility is not a nice-to-have you bolt on before launch. It is a design standard that, done properly, produces a site that works better for everyone.
What the law actually requires
Two frameworks matter. The Americans with Disabilities Act (ADA) has been interpreted by courts to cover websites as places of public accommodation, and healthcare providers are squarely in scope. Section 1557 of the Affordable Care Act adds specific nondiscrimination requirements for entities that receive federal funding, which includes most practices that accept Medicare or Medicaid. In 2024 the Department of Health and Human Services finalized a rule explicitly tying Section 1557 web accessibility to a technical standard.
That standard is WCAG, the Web Content Accessibility Guidelines, and the benchmark almost everyone now targets is WCAG 2.1 Level AA. It is the reference point courts cite, the level the HHS rule adopted, and the practical bar a healthcare site should meet. You do not need to become an expert in the guidelines, but you do need a site built to satisfy them.
What WCAG 2.1 AA looks like in practice
The guidelines are organized around four principles: content should be perceivable, operable, understandable, and robust. Translated into the things that actually break on healthcare sites, that means every image needs meaningful alternative text so a screen reader can describe it. Every form field, especially on booking and contact forms, needs a proper label. Color contrast between text and background has to be strong enough to read, which rules out the pale gray text so many designers love. The entire site has to be operable with a keyboard alone, because many users cannot use a mouse.
It also means captions on videos, a logical heading structure a screen reader can navigate, and controls that announce themselves correctly. None of this is exotic. It is the difference between a site built with accessibility in mind from the start and one where it was never considered. Getting it right is a core part of responsible web design and development, not a separate project you fund later.
The overlay trap
Faced with the problem, many practices reach for an accessibility overlay, a third-party script that promises to make any site compliant with one line of code. These tools are heavily marketed and they do not work as advertised. Advocacy groups and accessibility experts have repeatedly shown that overlays fail to fix underlying problems, sometimes make sites harder to use for people relying on assistive technology, and have not stopped lawsuits. A meaningful share of ADA web complaints now name sites that had an overlay installed.
There is no shortcut. Real accessibility comes from how the site is built: the HTML structure, the labels, the contrast, the keyboard support. A widget bolted onto a broken foundation just adds a layer of theater over the same barriers.
Accessible sites perform better for everyone
The framing that accessibility is a cost misses the upside. The same structure that helps a screen reader, clean semantic HTML and a logical heading hierarchy, is exactly what search engines parse to understand your pages, so accessibility and SEO pull in the same direction. Strong color contrast and large tap targets help every patient squinting at a phone in bright sun. Captioned videos help the person watching silently in a waiting room. Building to WCAG produces a site that is faster, clearer, and more usable across the board, which is why we treat it as part of good web design and development rather than an add-on.
Testing, not guessing
Accessibility claims should be verified, not assumed. That means automated scans to catch the obvious failures, plus manual testing with a keyboard and an actual screen reader like NVDA or VoiceOver, because automated tools catch only a fraction of real issues. A practice should know its site works for the patients it serves, and be able to show that it made a genuine effort if a complaint ever arrives.
How we approach it
Across our healthcare work, we build to WCAG 2.1 AA from the first line of markup rather than patching for it later, and we test with real assistive technology before launch. We would rather you have a site that is genuinely usable by every patient than a compliance badge that does not survive scrutiny. We are a small studio, we do the work ourselves, and we treat your site as a working tool rather than a brochure.
If you want a healthcare site that is accessible, defensible, and better for every patient, start a project with us.
More on Healthcare
Let’s build something that performs.
Tell us where you are and where you want to go — we’ll come back with a plan, not a calendar invite.