Healthcare Website Accessibility: Where to Focus First

Three forces converge on healthcare specifically. First, the audience: people managing conditions that affect vision, motor control, cognition, or attention rely on your booking and portal tools more than the average shopper relies on a checkout. An inaccessible site does not just lose a sale, it blocks care.

Second, the legal baseline has hardened. In the EU, the European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 and covers private-sector services including e-commerce and digital services, with WCAG 2.2 Level A and AA referenced through EN 301 549. Many public and university hospitals are separately covered by the EU Web Accessibility Directive (Directive (EU) 2016/2102), which uses the same EN 301 549 standard. The exact obligation depends on your structure and jurisdiction, but the technical target is consistent, and complaint and enforcement mechanisms are real.

Third, healthcare content is unusually hard to get right. It is dense, document-heavy, often produced by third parties such as labs and insurers, and frequently sits behind authentication where automated crawlers and casual testing never reach. That combination is exactly where accessibility quietly breaks.

Anchor your thinking in the four WCAG principles: content must be Perceivable, Operable, Understandable, and Robust. A scanned lab report fails Perceivable. A booking calendar you cannot reach without a mouse fails Operable. A consent form that rejects input with no explanation fails Understandable. Each maps to concrete, testable criteria.

Booking and intake forms are the single most common failure point because they combine custom widgets, validation, and time pressure. The recurring problems are specific and fixable:

• Date pickers built from <div> and <span> elements that a keyboard cannot operate, failing 2.1.1 (Keyboard). A native <input type="date">, or a custom widget with full arrow-key support and correct ARIA roles, is the fix.
• Placeholder-only fields with no persistent <label>, so a screen reader user who tabs back cannot recover what 'MM/YYYY' meant. Every field needs a real, visible label associated via for/id, satisfying 1.3.1 (Info and Relationships) and 3.3.2 (Labels or Instructions).
• Errors signalled by colour alone, such as a field border turning red, which fails 1.4.1 (Use of Color); red error text that is too faint also fails the 4.5:1 minimum of 1.4.3 (Contrast Minimum). Pair colour with a text message and move focus to it, meeting 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion).
• Tiny radio buttons and 'next' controls below the 24x24 CSS pixel floor of WCAG 2.2's new 2.5.8 (Target Size, Minimum), a real barrier for older patients and anyone with tremor.

WCAG 2.2 added criteria that hit intake flows hard. 3.3.7 (Redundant Entry) means a multi-step intake must not force patients to retype an address or date of birth they already entered. 3.3.8 (Accessible Authentication, Minimum) means you cannot require a patient to solve a puzzle or transcribe a code from memory to log in; an autocomplete-friendly field or a paste-able one-time code is required. 2.5.7 (Dragging Movements) means any slider, for pain scales or appointment time ranges, must have a non-drag alternative such as plus and minus buttons.

Build these on solid form foundations: real labels associated with their fields, error messages that name the problem and the fix, and autocomplete attributes on standard fields like name and address. Operating custom widgets without a mouse, full keyboard support and a visible focus indicator, is non-negotiable for booking flows.

Patient portals are high-risk precisely because they are gated. Sign-in, dashboards, messaging, and results live behind authentication, so the marketing site can pass a public scan while the most important journey, the one patients actually use, is never tested. You must test the authenticated experience as a logged-in user.

Portals are also where single-page-app patterns cause trouble. Content that updates without a full page load, new messages, a loaded result, a session-timeout warning, must announce itself via an ARIA live region, or a screen reader user simply will not know it changed. Focus management matters too: when a modal such as a consent dialog opens, focus must move into it and be trapped, and WCAG 2.2's 2.4.11 (Focus Not Obscured, Minimum) requires that a focused element is never fully hidden behind a sticky header or chat widget.

Two more 2.2 additions are tailor-made for portals. 3.2.6 (Consistent Help) asks that a help or contact mechanism appears in the same relative place across pages, valuable for the cognitive load of a sick or anxious user. And session-timeout dialogs that warn 'you will be logged out' must give a way to extend without re-authenticating from scratch. Note that 4.1.1 (Parsing) was removed in WCAG 2.2, so do not spend budget chasing obsolete parsing findings; browsers handle this now.

If your portal is a React or component-based app, the framework does not provide accessibility for free: accessible names, roles, and focus order are all yours to manage. Watch for keyboard traps in custom dropdowns and ensure tab order follows the visual order.

Healthcare runs on documents: lab results, after-visit summaries, consent forms, insurance explanations, intake packets. Many are scanned images of paper, which means they are pictures with no real text, completely invisible to a screen reader and impossible to enlarge without pixelation. A scanned PDF of a blood panel is, to a blind patient, a blank page.

An accessible PDF needs a genuine text layer (run OCR on scans), a tagged structure so headings and tables are navigable, a correct reading order, alt text on meaningful images, a document title, and a specified language. Data tables, ubiquitous in lab results, need proper header cells, not just visual rows and columns. Where a document is generated dynamically per patient, the template must be tagged once so every instance inherits the structure.

The most durable fix is to stop shipping critical information as PDF at all. An after-visit summary or a results page rendered as accessible HTML is responsive, reflows on a phone, works with every assistive technology, and avoids the PDF tagging burden entirely. Reserve PDF for documents that genuinely must be printed or signed. For the cases where PDF is unavoidable, our PDF accessibility guide covers tagging and remediation step by step.

You cannot fix everything at once, and you should not try. Prioritise by combining two axes: how critical the journey is to care, and how severe the barrier is. A keyboard trap on the booking flow outranks a low-contrast caption in the footer every time.

• Start with the booking-to-care path: find a clinic, book an appointment, complete intake, access results. Fix full blockers here before anything else; these are the journeys where a failure means no care.
• Within that path, fix barriers that stop a task entirely, keyboard traps, unlabelled form fields, image-only PDFs of results, before quality issues that merely slow people down.
• Run an automated scan to catch the high-volume mechanical issues fast: missing labels, contrast failures, missing alt text, missing page language. A free scan with AccessScan flags these in minutes and gives you a triaged starting list.
• Then test what automation cannot: log into the portal and operate every flow with the keyboard alone and with a screen reader. Automated tools catch only a portion of issues; keyboard-trap, focus-order, and meaningful-alt-text problems that block patients need a human.
• Bank the structural wins. Fixing the shared header, the design-system form components, and the global error pattern once propagates across hundreds of pages.

Make this repeatable rather than a one-off cleanup. Work through a structured checklist so coverage is consistent, add an automated scan to your release process so regressions are caught before they ship, and publish an honest accessibility statement that documents your conformance and gives patients a route to report problems.