- 01 / WHY IT MATTERS
Healthcare access starts before the front door
Patients may arrive with low vision, blindness, limited dexterity, hearing loss, cognitive disabilities, temporary injuries, or age-related changes. They may also be stressed, tired, or using an older phone. A barrier on a restaurant website is frustrating. A barrier on a healthcare website can interfere with access to care.
Title III of the Americans with Disabilities Act is a major source of website-accessibility litigation in the United States. In 2024, the U.S. Department of Health and Human Services also finalized an updated Section 504 rule for recipients of federal financial assistance, including specific web and mobile accessibility requirements tied to WCAG 2.1 AA, with compliance dates that vary by organization size. Practices should obtain legal advice for their exact obligations. Patient dignity, however, should not wait on a deadline.
- 02 / FOUNDATION
1. Structure pages so people can navigate them
Use one descriptive H1, then arrange H2 and H3 headings in a logical outline. Headings are navigation landmarks for many screen-reader users; choosing them only for visual size makes the page harder to understand. Use real lists, buttons, links, tables, and form controls instead of styled generic elements.
Add a “Skip to main content” link as the first useful keyboard control. Give every page a specific title and set the document language. Landmark elements such as header, nav, main, and footer help users move around. Link text should describe its destination. “View insurance information” is more useful than five identical “Click here” links.
- A visible-on-focus skip link reaches the main region.
- Heading levels form a sensible outline without arbitrary jumps.
- Page titles identify both the page and the practice.
- Links make sense when read outside the surrounding paragraph.
- 03 / VISUAL ACCESS
2. Check color, text, images, and zoom
WCAG 2.1 AA generally requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. User-interface components and meaningful graphics also need sufficient contrast. Do not communicate status through color alone; pair a red error outline with text that explains the error.
Write useful alternative text for informative images. A clinician portrait might identify the clinician, while a decorative sunrise can have empty alt text. Do not repeat the caption word for word. Charts need a text explanation of the conclusion and data. Test pages at 200% browser zoom and with larger text. Content should reflow without requiring two-dimensional scrolling for ordinary reading.
- Meet 4.5:1 contrast for normal text and 3:1 for large text.
- Do not put essential instructions inside images.
- Provide accurate alt text, or empty alt text for purely decorative images.
- Keep content usable at 200% zoom and common mobile widths.
- 04 / KEYBOARD AND FOCUS
3. Make every action work without a mouse
Unplug the mouse and start at the address bar. Press Tab through navigation, menus, dialogs, forms, calendars, and booking controls. Every interactive item must be reachable and operable with a keyboard. Focus order should follow the visual and reading order. Nothing should trap the user inside a widget.
Focus indicators must be visible against the surrounding colors. Do not remove the browser outline unless you replace it with something stronger. Menus should open and close predictably, including with Escape where appropriate. Carousels, autoplay media, and time limits need controls. If a third-party scheduler fails keyboard testing, placing it on your domain does not make the barrier disappear; raise the issue with the vendor or provide an equivalent accessible route.
- Tab reaches every control in a logical order.
- Enter and Space activate controls according to standard behavior.
- Focus is always visible and returns sensibly after a dialog closes.
- No keyboard trap exists in menus, calendars, chat, or embedded booking tools.
- 05 / FORMS
4. Label forms and make errors recoverable
Every input needs a programmatically associated label. Placeholder text is not a label: it disappears when someone types and often has poor contrast. Group related choices with fieldset and legend. State required fields in text and code, provide clear instructions before the form, and use appropriate autocomplete attributes for common personal information.
When submission fails, identify the fields with errors and explain how to correct them. Move focus to an error summary or otherwise announce the problem to assistive technology. Do not rely on red borders alone. For appointment requests, explain what happens next and whether the requested time is confirmed. Avoid collecting diagnosis details or other sensitive information in a standard email form; privacy and accessibility need to be designed together.
- Every field has a persistent, associated label.
- Required status and errors are conveyed with text, not color alone.
- Error messages describe the correction and are announced.
- Success messages are perceivable and explain the next step.
- 06 / MEDIA AND MOTION
5. Cover audio, video, animation, and time limits
Prerecorded video with meaningful speech needs accurate captions. Audio-only content needs a transcript, and video may need audio description when important visual information is not available in the soundtrack. Auto-playing audio is especially disruptive for screen-reader users and should be avoided.
Animations and parallax effects can cause nausea or distraction. Respect the reduced-motion setting and provide controls for moving content. Avoid flashes that could trigger seizures. If a form or portal session expires, warn the user and allow more time when security rules permit. Healthcare tasks often take longer for users who rely on assistive technology.
- 07 / REAL TESTING
6. Test with tools, a screen reader, and people
Automated scanners are useful for finding missing labels, contrast failures, duplicate IDs, and some structural errors, but they cannot decide whether alt text is meaningful or a booking flow makes sense. Combine automation with keyboard testing and at least one screen reader. VoiceOver is built into Apple devices; NVDA is a free option on Windows.
Test the homepage, contact page, location pages, service pages, forms, documents, and embedded tools. Include disabled users in usability testing when possible and publish an accessibility contact method that receives a real response. Keep an issue log with severity, owner, and target date. Accessibility is ongoing maintenance, especially when staff add content or vendors update widgets.
- Run automated checks, then verify every result manually.
- Complete key tasks with keyboard only and with a screen reader.
- Check PDFs and third-party tools, not only HTML pages.
- Retest after redesigns, plugin updates, and new content.
- 08 / PRACTICAL STANDARD
Use WCAG as the floor, not the finish line
A checklist reduces obvious barriers, but conformance is not the same as a good patient experience. Plain language, predictable navigation, helpful error messages, and multiple contact options often determine whether someone can finish a task. Document what you tested and what remains.
Start with the pages tied directly to care access, then work through the rest of the site. Fix critical blockers first. Do not buy an overlay that promises instant compliance; automated widgets cannot repair inaccessible source code, missing context, or an unusable third-party workflow. The durable approach is accessible design, correct code, real testing, and a process for keeping it that way.