Web Accessibility for Medical Websites: A Practical WCAG Guide

01Your Audience Is the Accessibility Audience

Every website should be accessible. Medical websites have a sharper reason than most: your visitors are disproportionately the people that inaccessible design excludes.

Ophthalmology and diabetes patients often have reduced vision. Orthopaedic and neurology patients may have limited fine motor control that makes small tap targets and drag interactions genuinely difficult. Geriatric and cardiology audiences skew older, with the vision, hearing, and dexterity changes that come with age. ENT and audiology patients may not hear your video. And almost every visitor to a medical website is under some degree of stress, which measurably reduces reading comprehension and patience for confusing interfaces.

An inaccessible booking form on a restaurant website loses a reservation. An inaccessible booking form on a hospital website means a patient with low vision cannot request an appointment. That is the argument that gets accessibility funded, and it happens to be true.

There is also a legal dimension that varies by market — the Americans with Disabilities Act and Section 508 in the United States, the Rights of Persons with Disabilities Act and associated government website guidelines in India, the Equality Act in the UK, and the European Accessibility Act. The common technical reference point across almost all of them is WCAG, at level AA. Build to WCAG 2.2 AA and you are broadly aligned everywhere.

02Start With the Six Failures That Cause Most of the Damage

Automated scans typically catch a minority of real accessibility problems, but the ones they catch are also the most common. Fix these first.

Colour contrast. Body text needs a contrast ratio of at least 4.5 to 1 against its background, and large text at least 3 to 1. The usual healthcare offenders are light grey body copy on white, pale blue links, and text placed over hero images. Also check your buttons in their disabled and hover states, and your form placeholder text, which is almost always too light.

Missing alternative text. Every meaningful image needs a description of what it conveys. A photograph of a consultation room should describe the room. A diagram explaining a procedure needs the explanation in text, not just the word diagram. Decorative images should carry empty alt text so screen readers skip them rather than announcing a filename.

Unlabelled form fields. Placeholder text is not a label. It disappears when the patient starts typing and it is not reliably announced by assistive technology. Every field needs a visible, persistent, programmatically associated label. This matters most on the appointment form, which is the field set most likely to be abandoned.

Keyboard traps. Many patients navigate by keyboard alone. Tab through your entire site without touching the mouse. If you cannot escape a modal, dismiss a cookie banner, close a chat widget, or reach the booking button, you have a blocker. Third-party chat and popup widgets are the most frequent cause.

Invisible focus indicators. Designers often remove the focus outline because it looks untidy. For a keyboard user, that removes the cursor. Replace it with a designed indicator that meets contrast requirements — never delete it.

Video without captions. Doctor introduction videos and procedure explainers are among the highest-converting assets on a medical site, and uncaptioned video excludes deaf and hard-of-hearing patients entirely. It also excludes the much larger group watching without sound.

03Healthcare-Specific Patterns That Need Extra Care

Appointment booking. This is the flow where accessibility failures cost you real patients. Date pickers are notorious — many calendar widgets are unusable by keyboard and unreadable by screen readers. Always allow direct text entry of a date as an alternative. Announce validation errors clearly, in text, next to the field, not only as a red border. Never impose a session timeout on a booking form without warning and an option to extend.

Symptom checkers and multi-step forms. Announce progress in text, allow returning to previous steps, and preserve entered data. A patient who has to restart a seven-step form because step five failed silently will not restart.

Emergency information. Emergency numbers and directions must be reachable by keyboard within the first few tab stops, must not be trapped inside a carousel or accordion, and must be readable at 200 percent zoom.

Medical PDFs. Consent forms, patient information leaflets, and price lists distributed as scanned PDFs are effectively invisible to assistive technology. Publish them as HTML pages instead — which is better for search visibility too — and keep the PDF as a printable secondary option.

Interactive maps. An embedded map is not usable by everyone. Always publish the full address as selectable text alongside it, plus written directions.

04How to Test Without a Specialist Budget

Automated tools first. Run an accessibility scanner across your key templates — homepage, service page, doctor profile, blog article, contact and booking. These catch contrast, missing alt text, and structural problems in minutes and cost nothing.

Then do four manual checks that take under an hour and find what scanners cannot.

Unplug your mouse and complete the two journeys that matter: find a doctor and book an appointment. Note every point where you get stuck.

Zoom the browser to 200 percent and then 400 percent. Text should reflow rather than requiring horizontal scrolling, and nothing should overlap or disappear.

Turn on your operating system's built-in screen reader and listen to a service page. It will be uncomfortable and you will learn more in ten minutes than from any report.

Read your headings in outline order. They should form a logical structure with a single H1 and no skipped levels. Headings used purely to make text bigger are one of the most common structural defects on medical sites.

05Build It Into the Process, Not the Backlog

Accessibility added as a remediation project decays within two release cycles. Add it to how work gets made instead.

Put contrast requirements into your design system tokens so a non-compliant colour pair cannot be selected. Add an accessibility line to your definition of done for every front-end ticket. Run an automated scan in your build pipeline so a regression fails the build rather than reaching production. Give your content team a short rule set — write alt text, use real headings, describe links meaningfully rather than writing click here, and caption every video.

One warning worth stating plainly: overlay widgets that promise instant compliance from a single script do not deliver it, are widely criticised by disability advocacy organisations, and have featured in legal complaints rather than preventing them. There is no script that substitutes for building the site correctly.

The upside is that almost everything on this list improves the site for everyone. Higher contrast helps a patient reading outdoors on a phone. Clear labels reduce form abandonment across the board. Captions increase video completion. Proper heading structure helps search engines parse your content. Accessibility done properly is simply better design applied to an audience that cannot tolerate bad design.