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 questions are always the same. Where do we start? How much of this can we do ourselves? This note answers both.

It assumes you have gone through the ten warning signs and found several on your site. It is written for a typical clinic website on WordPress or a similar page builder. The sequence holds for any platform.

The order is deliberate. Each step sits where it does because of how much legal and patient-facing risk it removes for the effort. Work from the top down and most of your exposure is gone before you reach the hard parts.

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

Open your theme or customizer settings. Find the body text color, the link color and any "muted" or "light" text style. Check each one against its background with a contrast checker. The WebAIM checker is free and has been the industry reference for years.

Aim for 4.5 to 1 on normal text. Text over about 24 pixels, or bold text over about 19, needs 3 to 1.

Nearly every template ships with a body gray that fails. Darken it. If the brand palette uses a light teal or a pastel for text on white, move that color to backgrounds and accents. 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 many older patients. It also 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 carries information gets a short description of what it shows and why it is there. Describe photos of the physician, the office, the entrance and the exam rooms the way a patient would want them described.

Decorative images get an empty alt attribute, so screen readers skip them. That means dividers, background textures, and icons that sit next to text saying the same thing.

Write alt text for the reader first. If the photo shows the clinic in West Palm Beach, "pediatric clinic in West Palm Beach" fits, so use it. If it does not fit, leave it out. Keyword-stuffed alt text can bring an accessibility complaint and a search penalty at the same time.

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

Each page gets one <h1>, the page title. Major sections get <h2>. Subsections get <h3>. Nothing skips a level.

Page builders make this easy to get wrong, because they let anyone pick a heading level by how big it looks. Fix the sizes in the stylesheet once. Then the correct level also looks correct, and editors stop reaching for the wrong one.

While you are in each page, rewrite the link text. "Click here" and "learn more" become "Request an appointment" and "Read our vaccine policy." Search engines and screen readers both read 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)

The risk gets serious here, because forms are where people try to become patients.

Every input needs a visible <label> bound to it with for and id. Placeholders can stay as hints, but they cannot be the only label. Required fields say "required" in words. Groups of radio buttons or checkboxes sit inside a <fieldset>, with a <legend> that names the question.

Most form plugins do all of this correctly when you use their label fields and keep the question out of the placeholder. If the form was built by hand, or by an older plugin, you may need help at this step.

Then test the error handling. Submit the form empty. A screen reader should announce what went wrong. The error text should appear next to the field and say, in words, what to do. 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 must trap focus while it is open and return focus when it closes. That includes a cookie notice, a pop-up promotion and a telehealth login. Anything that appears on hover must also appear on focus, or be available some other way.

On a page-builder site the usual culprits are the mobile hamburger menu, the mega menu, image carousels, and "cards" made clickable with JavaScript on a div. Rewrite each one with real <button> and <a> elements. If the theme itself is the problem, this step becomes a theme change. Stop and 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 takes 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 (time varies)

List every PDF the site links to. Patient forms come first.

The right fix for an intake packet is a web form that submits securely to the practice. It also ends the print-and-bring-it-in routine that patients hate. Where a PDF has to stay a PDF, it needs to be a tagged, text-based document with a proper reading order. Any modern word processor will export one, if the source used real headings and real form fields. Replace every scanned image of a paper form.

Every video gets captions. The hosting platform's automatic captions are a starting point, and they need correcting, especially for drug names and medical terms. A transcript below the video costs almost nothing and gives search engines more to index.

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

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

Put up a plain accessibility statement page in its place. Name the standard you aim for, WCAG 2.1 AA. Describe any known limits honestly. Give a monitored email address and phone number for reporting barriers, and answer reports within a few business days. In front of a judge, a documented, good-faith process for handling complaints is worth more than any widget.

Step 8: Test with the real thing

Automated scanners find about a third of WCAG issues. Run one, and keep going.

Spend thirty minutes with a screen reader. VoiceOver is built into every Mac and iPhone, and NVDA is free on Windows. Try the three things a patient does: find the hours and address, find what the practice treats, and request an appointment. Do all three with the screen on and the mouse unplugged. Then do them again with the screen off. If you can, 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. Keep the plugin count small, so there is less to break.

Some sites are old and cluttered enough that steps four through six become a fight with the theme. Then 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 upkeep than the one it replaced. That is usually the right call. Make it while the federal deadline is still a year away.