Field Notes · 05

How to fix an inaccessible medical website, in the order that matters

A working sequence for bringing a clinic website up to WCAG 2.1 AA without a rebuild, ordered by how much risk each step removes per hour of effort.

Patrick Jean-Baptiste · September 12, 2026

Once a practice knows its website has accessibility problems, the next question is always the same: where do we start, and how much of this can we do ourselves? This note answers both. It assumes you have already gone through the ten warning signs and found several of them on your site. It is written for a typical clinic website on WordPress or a similar page builder, though the sequence holds for any platform.

The order below is deliberate. Each step is placed by how much legal and patient-facing risk it removes for the effort it takes. Do them top to bottom and you will have removed most of your exposure before you reach the hard parts.

Step 1: Fix the contrast (an hour, no developer needed)

Open your site's theme or customizer settings and find the body text color, link color and any "muted" or "light" text style. Run each one against its background with a contrast checker; the WebAIM checker is free and has been the industry reference for years. You are aiming for 4.5 to 1 on normal text and 3 to 1 on text over about 24 pixels or bold text over about 19.

Nearly every template ships with a body gray that fails. Darken it. If the brand palette has a light teal or a pastel that is used for text on white, it moves to backgrounds and accents only. Check button text against button backgrounds too; white text on a pale brand color is one of the most common failures on medical sites.

This step alone makes the site readable for a large share of older patients and removes the most visible ground for a complaint.

Step 2: Write real alt text (an afternoon, no developer needed)

Go through the media library. Every image that conveys information gets a short description of what it shows and why it is there. Photos of the physician, the office, the entrance and the exam rooms get described as a patient would want them described. Decorative images, meaning dividers, background textures and icons that sit next to text that already says the same thing, get an empty alt attribute so screen readers skip them.

Write alt text for the reader first. If a phrase like "pediatric clinic in West Palm Beach" fits naturally because the photo is of the clinic in West Palm Beach, use it. If it does not fit, leave it out. Alt text stuffed with keywords is one of the few things that can trigger both an accessibility complaint and a search penalty at once.

Step 3: Repair the heading outline (an afternoon, no developer needed)

Each page gets one <h1>, which is the page title. Major sections get <h2>. Subsections get <h3>. Nothing skips a level. Page builders make this hard to get wrong on purpose and easy to get wrong by accident, because they let anyone choose a heading level based on how big it looks. Fix the sizes in the stylesheet, once, so that the correct level also looks correct, and editors stop reaching for the wrong one.

While you are in each page, rewrite link text. "Click here" and "learn more" become "Request an appointment" and "Read our vaccine policy." Search engines and screen readers both read the link text alone, out of context, and both reward you for being specific.

Step 4: Label every form field (half a day, may need a developer)

This is where the risk gets serious, because forms are where patients try to become patients. Every input needs a visible <label> bound to it with for and id. Placeholders can stay as hints but cannot be the only label. Required fields say "required" in text. Groups of radio buttons or checkboxes sit inside a <fieldset> with a <legend> that names the question.

Most form plugins will do all of this correctly if you use their label fields instead of typing the question into the placeholder. If the form was built by hand or by an older plugin, this is the point where you may need help.

Then test error handling. Submit the form empty. A screen reader should announce what went wrong, the error text should appear next to the field, and the message should say what to do, in words. Red borders alone fail.

Step 5: Make the site work without a mouse (one to three days, developer needed)

Tab through every page. Every interactive element must receive focus, in a sensible order, with a visible outline. The main navigation must open and close from the keyboard. Any modal, whether a cookie notice, a pop-up promotion or a telehealth login, must trap focus while open and return it when closed. Anything that only appears on hover must also appear on focus or must be available another way.

On a page-builder site the usual culprits are the mobile hamburger menu, the mega menu, image carousels and "cards" that are made clickable with JavaScript on a div instead of being real links. Each of these gets rewritten with proper <button> and <a> elements. If the theme itself is the problem, this step becomes a theme change, and it is worth pausing to ask whether the rest of the site justifies keeping it.

Add a "skip to main content" link as the first focusable element on every page. It is one line of HTML and a few lines of CSS, and it is one of the first things an auditor looks for.

Step 6: Deal with the PDFs and videos (varies)

Inventory every PDF the site links to. Patient forms come first. The right fix for an intake packet is to rebuild it as a web form that submits securely to the practice, which also ends the print-and-bring-it-in routine that patients hate. Where a PDF must stay a PDF, it needs to be a tagged, text-based document with a proper reading order, which any modern word processor will export if the source document used real headings and real form fields. Scanned images of paper forms get replaced, full stop.

Every video gets captions. Auto-generated captions from the hosting platform are a starting point and need to be corrected, especially for drug names and medical terms. A transcript below the video costs almost nothing and doubles as indexable content.

Step 7: Remove the overlay widget, add an accessibility statement

If an accessibility overlay is installed, uninstall it after the steps above are done. It was never fixing anything, it interferes with assistive technology that patients already use, and its presence has been cited against defendants in litigation.

Replace it with a plain accessibility statement page. State the standard you aim for, WCAG 2.1 AA, describe any known limitations honestly, and give a monitored email address and phone number for reporting barriers. Respond to reports within a few business days. A documented, good-faith process for handling accessibility complaints is worth more in front of a judge than any widget.

Step 8: Test with the real thing

Automated scanners find perhaps a third of WCAG issues, so run one, but do not stop there. Spend thirty minutes with a screen reader. VoiceOver is built into every Mac and iPhone; NVDA is free on Windows. Try to do the three things a patient does: find the hours and address, find what the practice treats, and request an appointment. If you can do all three with the screen on and the mouse unplugged, and then again with the screen off, you are most of the way there.

Keeping it fixed

Accessibility decays. A new staff member uploads a flyer as an image, a plugin update changes the menu markup, a designer lightens the gray again. Put the ten-sign check on a quarterly calendar, make alt text a required field in the media library, and keep the number of plugins small so there is less to break.

If the site is old enough and cluttered enough that steps four through six become a fight with the theme, it is often faster to rebuild on a clean, minimal base and carry the content over. Done properly, the rebuilt site is accessible on day one, loads faster, and needs less maintenance than the one it replaced. That is usually the right call, and it is a call worth making while the federal deadline is still a year away.