ADA and WCAG Web Accessibility for Healthcare Websites. Requirements and Checklist

Healthcare organizations face higher web accessibility risk than most businesses. The patients who most need healthcare services are often the same patients most likely to rely on assistive technology: older adults with vision or motor impairments, patients managing chronic conditions that affect dexterity or cognition, and individuals with disabilities seeking care providers who can help them. When a healthcare site fails accessibility standards, it blocks the patients you’re supposed to serve. It also creates legal exposure that has resulted in settlements and DOJ enforcement actions against healthcare organizations. This guide covers what’s required, where healthcare sites most commonly fail, and how to audit and fix accessibility issues.

Why Healthcare Sites Face Higher ADA Risk

The DOJ has interpreted Title III of the Americans with Disabilities Act to cover websites as “places of public accommodation.” This interpretation has been increasingly enforced, and healthcare organizations are a frequent target for several reasons:

• Healthcare services are essential, not optional. A visually impaired patient who can’t navigate a dental practice’s website to find hours and book an appointment faces a real barrier to care.
• Healthcare organizations tend to have resources to pay settlements, making them attractive targets for plaintiff attorneys who specialize in ADA website lawsuits.
• Healthcare sites have complex functionality (appointment forms, booking calendars, patient portals) that’s particularly prone to accessibility failures because it requires more than basic HTML to implement correctly.
• Most healthcare site builds come from agencies that treat accessibility as an afterthought, resulting in sites that look compliant but fail when tested against the actual standard.

The frequency of ADA website lawsuits has increased significantly in recent years. Healthcare is among the top five most sued industry verticals. The cost of a settlement typically runs $25,000 to $100,000 plus attorney fees. Proactive remediation costs a fraction of that.

WCAG 2.1 AA Explained

The Web Content Accessibility Guidelines (WCAG) 2.1 AA is the accepted technical standard for ADA compliance. It’s organized around four principles, often abbreviated as POUR:

Perceivable

Information and user interface components must be presentable to users in ways they can perceive. For healthcare sites, this means: all images that convey information have text alternatives (alt text), videos have captions, and content isn’t conveyed through color alone. A red asterisk on a required form field isn’t sufficient if there’s no text label identifying the field as required. A patient using a screen reader sees no color.

Operable

User interface components and navigation must be operable. For healthcare sites, this means every interactive element (links, buttons, form fields, booking calendars, navigation menus) must be reachable and operable with a keyboard alone. No mouse required. Patients with motor disabilities rely on keyboard navigation or switch access. A booking calendar that requires clicking with a mouse excludes them from making appointments.

Understandable

Information and the operation of the user interface must be understandable. For healthcare sites, this means form error messages explain what’s wrong and how to fix it (“Please enter a valid phone number in the format 555-555-5555” rather than “Error: invalid input”), navigation is consistent across pages, and unusual terms are explained. Healthcare content uses medical terminology that may need clarification for some patients.

Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. For healthcare sites, this means using semantic HTML (proper heading hierarchy, landmark regions, list markup for lists), ARIA attributes used correctly where semantic HTML isn’t sufficient, and markup that validates without errors that would confuse screen readers.

Accessibility Checklist for Healthcare Sites

Images

• All meaningful images have descriptive alt text. Provider photos should describe who the person is (“Dr. Sarah Chen, board-certified orthopedic surgeon”). Facility photos should describe what’s shown. Before/after images should describe the condition and result.
• Decorative images (backgrounds, spacer images, purely aesthetic elements) have empty alt attributes (alt=””) so screen readers skip them.
• Logos and icons that convey information have appropriate alt text.

Color Contrast

• Normal text (under 18pt or 14pt bold): minimum 4.5:1 contrast ratio against the background.
• Large text (18pt or 14pt bold and larger): minimum 3:1 contrast ratio.
• User interface components (form input borders, button outlines, focus indicators): minimum 3:1 against adjacent colors.
• Healthcare sites with light-blue or gray palettes frequently fail this for light-gray body text on white backgrounds. Run every text color combination through a contrast checker (WebAIM Contrast Checker).
• CTA buttons get checked. A light-blue button with white text often fails. A dark-blue or high-contrast button with white text passes.

Forms

• Every form field has a programmatically associated label using the for/id attribute pair or aria-labelledby. Placeholder text alone doesn’t count as a label.
• Required fields are marked both visually and programmatically (aria-required=”true” or the HTML required attribute).
• Error messages describe the problem specifically and are associated with the field that has the error, not just displayed at the top of the form.
• Form instructions (like date format for appointment date fields) are provided before the field, not only as placeholder text.
• Appointment booking forms and contact forms get tested with keyboard-only navigation, end to end, including submitting the form.

Keyboard Navigation

• Every interactive element (links, buttons, form fields, menu items, modal dialogs, booking calendars) is reachable by pressing Tab.
• The Tab order follows a logical reading sequence. Jumping from the header to the middle of the page content confuses keyboard users.
• Visible focus indicators exist on every interactive element. Many healthcare themes have suppressed focus outlines for aesthetic reasons. This is an accessibility failure.
• No keyboard traps. If a user tabs into a modal dialog (like a booking calendar or lightbox), they can also tab out of it without using a mouse.
• Date pickers in booking calendars are a common keyboard navigation failure point. Calendar widgets that only work by clicking with a mouse exclude patients who use keyboard navigation.

Videos

• All pre-recorded video content has synchronized captions. This applies to patient education videos, procedure explainer videos, and provider introduction videos.
• Auto-playing videos include a mechanism to pause them. Auto-play with audio is a WCAG failure and also a user experience problem for all patients, not just those with disabilities.
• Videos that contain important information have audio descriptions or transcripts as an alternative for patients who are deaf or hard of hearing.

Screen Reader Compatibility

• Semantic HTML used throughout: headings in proper hierarchy (H1, then H2, then H3 — no skipping levels), lists for list content, nav elements for navigation, main for main content, footer for footer.
• ARIA landmarks correctly identify page regions (header, main, navigation, footer, aside). Screen reader users navigate by jumping between landmarks.
• ARIA attributes (aria-label, aria-describedby, aria-expanded, aria-hidden) are used where semantic HTML is insufficient. They’re not used to override correct semantic HTML.
• Dynamic content updates (appointment availability loading, form validation messages appearing) notify screen readers using ARIA live regions.

PDFs and Patient Forms

• Patient intake forms and health history forms provided as PDFs need to be tagged PDFs that are readable by screen readers.
• For practices that provide intake forms as PDF downloads, an HTML alternative version improves accessibility and patient experience for patients who complete forms on mobile.
• PDFs with scanned images of text (common for older forms that were scanned and uploaded) are completely inaccessible to screen readers. These need to be rebuilt as proper tagged PDFs or replaced with HTML forms.

Common Accessibility Violations Found on Healthcare Sites

The failures we find most consistently when auditing healthcare sites:

• Missing form labels on appointment booking and contact forms. Placeholder text inside the input field is not a label.
• Poor color contrast on light-colored CTA buttons (light blue on white, gray on white, yellow on white). These fail the 3:1 minimum for UI components.
• Inaccessible date pickers in booking calendars. Calendar widgets built with non-semantic HTML and no keyboard support are among the most common and consequential failures on healthcare sites.
• Missing alt text on provider headshots. These are meaningful images that identify the provider a patient will be seeing. Screen reader users should know who is in the photo.
• Auto-playing hero videos without pause controls. Common on practices that want high-energy above-fold content.
• Focus indicators removed via CSS. A declaration of outline: none or outline: 0 on :focus removes visibility for keyboard users navigating the site.

How to Audit Healthcare Site Accessibility

Automated Tools

WAVE (wave.webaim.org), axe DevTools browser extension, and Lighthouse Accessibility audit all run automated checks. Automated tools catch about 30 to 40% of WCAG failures. They’re fast and should be run on every page, but they don’t catch issues that require human judgment: whether alt text is actually descriptive, whether reading order makes logical sense, or whether form instructions are clear enough for a patient with cognitive disabilities.

Manual Testing

Manual keyboard navigation testing: disconnect your mouse and try to use the site with only Tab, Shift-Tab, Enter, and arrow keys. Book an appointment. Find a provider. Fill out a contact form. If you can’t complete these tasks with keyboard only, neither can patients who rely on keyboard navigation.

Screen Reader Testing

NVDA (free, Windows) and JAWS (Windows, commercial) are the most commonly used desktop screen readers. VoiceOver is built into macOS and iOS. Testing with a screen reader catches issues automated tools miss: incorrect ARIA usage that creates confusing announcements, missing landmark regions, heading hierarchy problems, and form instructions that don’t get read at the right point in the interaction.

Remediation Approach

Accessibility remediation for an existing healthcare site should be prioritized by severity and conversion impact:

• Immediate fixes: Form labeling failures (block patients from completing appointment requests), keyboard traps (prevent patients from using booking calendars), and auto-playing videos with audio (disruptive to all users).
• High priority: Color contrast failures on CTAs and body text, missing alt text on provider photos, missing focus indicators, date picker accessibility.
• Standard remediation: PDF accessibility, ARIA landmark implementation, heading hierarchy cleanup, video captions for existing content.

For practices with extensive existing content, remediation happens in phases. New content and new pages get built to WCAG 2.1 AA from the start. Existing content gets fixed based on severity and traffic (fix the most visited pages first).

Ongoing Accessibility Maintenance

Accessibility isn’t a one-time fix. Plugin updates can introduce regressions: a form plugin update removes label associations, a slider component update loses keyboard support, a new button component style falls below contrast requirements. Monthly accessibility spot-checks after plugin updates are part of a complete healthcare website maintenance routine.

New content added after launch needs to be created with accessibility in mind. Images need alt text at upload. Videos need captions before publishing. New forms need label associations before going live. Staff who add content need basic accessibility training to prevent new violations from accumulating.

For the broader technical foundation that supports accessible healthcare websites, see our guide to healthcare website development. For maintaining accessibility compliance alongside other site maintenance tasks, our overview of healthcare website maintenance services covers what an ongoing maintenance plan should include.