What Happens If Your Healthcare Website Is Not Accessible? ADA Next Steps

Reviewed October 2026

An inaccessible healthcare website can make it harder for people to find care information, understand services, complete a form, request an appointment, or use a patient-access feature without help. For a healthcare organization, the immediate response is not to chase an “ADA-compliant” badge. It is to identify the patient tasks that matter, find and remove barriers, test the fixes with people and assistive technology, and obtain qualified legal or accessibility guidance for the organization’s specific obligations.

This guide provides general information about website accessibility. It is not legal advice, a certification, or a conclusion that a website meets any particular legal or technical standard. Accessibility obligations can differ by organization, service, funding, jurisdiction, technology, and facts.

What “Not Accessible” Can Mean for a Healthcare Website

Website accessibility is about whether people with disabilities can use the information and functions a practice makes available online. A barrier may prevent a visitor from reading service information, understanding a provider page, using a screen reader with an image or heading, navigating without a mouse, watching a video without captions, or correcting an error in a request form.

For a healthcare practice, the most consequential barriers often appear in patient-access journeys: choosing a location, comparing services, finding contact information, requesting an appointment, submitting a form, locating a portal, accessing a virtual-care link, or understanding what happens next. A page can look polished and still create a barrier if the task cannot be completed by a keyboard user, a screen-reader user, or someone who needs text to resize.

What Happens When a Patient-Access Task Has a Barrier

The first impact is practical. A person may not be able to obtain the information or complete the task independently. For example, a form without clear labels or error messages can be difficult for a screen reader to interpret. A scheduling widget that cannot be used by keyboard may block a visitor from requesting care online. A video without captions may exclude someone from information presented only in the video.

There can also be organizational and legal implications. The U.S. Department of Justice says the ADA applies to state and local governments and to businesses open to the public. Its examples of public accommodations include hospitals and medical offices. The Department explains that inaccessible website features can limit access to information, goods, services, and privileges offered online. The exact obligations and risks for a particular healthcare organization require fact-specific advice from qualified counsel or accessibility professionals.

Accessibility should not be framed only as legal exposure. A barrier in a high-intent journey can create unnecessary patient friction and extra work for staff. The strongest response is to document the barrier, prioritize the affected task, fix it, verify the result, and make accessibility part of the release process for future content and functionality.

ADA, Section 1557, and WCAG Serve Different Purposes

The ADA is a civil-rights law. DOJ says Title II covers state and local governments, while Title III covers businesses open to the public. DOJ also says businesses and public entities have flexibility in how they meet the ADA’s general nondiscrimination and effective-communication requirements. Its general web guidance identifies WCAG and Section 508 as useful technical resources, but it does not create a single universal private-practice website checklist.

Section 1557 is a separate civil-rights provision. HHS OCR says it applies to health programs or activities, any part of which receives HHS financial assistance, HHS-administered health programs, and participating Marketplace issuers. Covered entities must take appropriate steps for effective communication with people with disabilities and make programs and activities provided through electronic and information technology accessible to people with disabilities, subject to stated undue-burden and fundamental-alteration limitations. Whether and how Section 1557 applies to a specific organization should be reviewed with qualified counsel.

WCAG is a technical accessibility standard from the World Wide Web Consortium. WCAG 2.2 organizes accessibility around content being perceivable, operable, understandable, and robust. It provides testable criteria at A, AA, and AAA levels. A documented WCAG target can guide design and remediation work, but a conformance level is not a substitute for the organization’s legal analysis or for testing how real people use important patient-access tasks.

Do not treat the Title II web and mobile-app accessibility rule as a universal private-practice deadline. That rule addresses state and local government entities and uses WCAG 2.1 Level AA. Healthcare organizations should determine their own applicable requirements with qualified advisors.

Prioritize the Patient Journeys That Matter Most

Start with a short inventory of the journeys that a prospective or current patient must be able to complete. Include service and provider pages, location and hours information, contact paths, appointment-request forms, online scheduling, portal links, payment or bill-pay links, virtual-care links, downloadable documents, videos, and emergency instructions.

For each journey, record the page or tool, its owner, the intended task, a test method, known barriers, the impact if the task fails, the remediation owner, target date, and retest result. Keep third-party tools in the inventory. A booking, chat, maps, payment, or patient-portal vendor may be part of the user journey even when the practice did not build the interface.

Address barriers in tasks that affect patient access first. A useful order is: emergency or time-sensitive routing; appointment and contact paths; forms and scheduling; service, provider, and location information; portal and virtual-care handoffs; then lower-priority content and marketing enhancements. This is an operational decision framework, not a legal risk ranking.

Start With a Focused Accessibility Review

A focused review should combine automated checks, keyboard testing, manual inspection, and feedback from people who use assistive technology. Automated tools can help find repeatable issues, but DOJ cautions that a clean automated report does not necessarily mean a website is accessible. Use automation to find candidates, then test the actual user task.

Review each core page and flow for clear headings, informative text alternatives for meaningful images, sufficient contrast, visible focus, keyboard operation, descriptive links, readable text, captions for relevant video, understandable form labels, clear instructions, and usable error messages. Check zoom and mobile behavior as part of the same workflow.

Ask a practical question for every finding: can the person complete the intended task without having to guess, rely on color alone, use a mouse, or call for help because the online path failed? Document what happened and retain evidence of the retest after a fix.

Do Not Promise Rankings or a Legal Outcome

Accessibility work can make a website more usable and can support clearer, more descriptive, crawlable content. Google encourages useful, well-organized content, descriptive titles and links, high-quality images near relevant text, and meaningful alt text. Google does not promise that a particular change will improve rankings, and accessibility should not be sold as a guaranteed SEO tactic.

Improve the page because patients need to use it, then measure the right outcomes. Track completion of the key task, form-error patterns, support requests about access barriers, appointment-request completion where appropriate, and the number and status of resolved issues. Use Search Console to observe how the revised content is discovered, but do not conflate a higher search position with proof that a website is accessible.

Make Accessibility an Ongoing Release Standard

Accessibility can regress whenever content, a template, a form, a third-party widget, or a campaign landing page changes. Assign ownership across content, design, development, operations, and vendor management. Give every new page and important change a pre-release accessibility check, maintain an issue-reporting path for visitors, and schedule recurring reviews of high-impact journeys.

Use the companion healthcare website accessibility checklist for the practical checks across content, media, navigation, forms, booking, and release governance. For a separate review of website tracking and data-flow questions, see the healthcare website tracking audit.