ADA compliant website design means building a site that meets WCAG 2.1 Level AA, so that people using screen readers, keyboards, and magnification get the same access to your practice as everyone else. About 1 in 4 US adults lives with a disability according to the CDC, which makes this a reach problem before it is a legal one.
Most advice on the subject stops at “add alt text and fix your contrast.” That is roughly a fifth of the work, and it is the fifth automated checkers already catch. This is the rest: the web design decisions that make a website accessible, the legal requirements each one maps to, the deadlines that moved in 2026, and what the three remediation paths actually buy you.
If you want the legal side in depth, including demand letters, Title III exposure, and state statutes, start with our guide to ADA compliance web design. This piece is about the build.
What does it mean for a website to be ADA compliant?
An ADA compliant website gives people with disabilities equal access to your information and services. In practice that means conforming to the Web Content Accessibility Guidelines 2.1 Level AA, the technical standard federal regulators have adopted. The Americans with Disabilities Act of 1990 creates the duty. The WCAG guidelines define how you satisfy it.
WCAG has three conformance levels: A, AA, and AAA. Level AA is the one regulators adopted and the one courts reference, so it is the target that minimizes legal risk. WCAG 2.0 was published in 2008 and WCAG 2.1 followed in 2018, adding the mobile and low-vision criteria that matter most on a practice site.
There is no federal certification, no badge, and no agency that approves a compliant website. Compliance is a property of the site itself, tested against 50 success criteria at Level AA. Website owners cannot buy it, and no vendor can grant it.
Where the ADA applies to your website
The ADA applies to your public-facing online content, your patient portal, your intake forms, your appointment scheduler, your mobile applications, and the PDFs you publish. It applies to third-party tools embedded in your site under a contractual or licensing arrangement, which is where most practices get caught. Your booking widget is your problem, not only your vendor’s.
Does ADA compliance apply to websites?
Yes. The Department of Justice has held for years that the ADA covers the web content of covered entities, and in April 2024 it published a binding technical standard for state and local governments at 28 CFR 35.200. Separately, HHS adopted WCAG 2.1 Level AA for recipients of its financial assistance at 45 CFR 84.84.
Private practices sit under Title III, which has no published technical rule. Courts hearing Title III website cases have overwhelmingly used WCAG 2.1 Level AA as the practical measure, which is why these web accessibility standards are the right target regardless of which category you fall into.
Who needs to be ADA compliant?
Three separate regimes can reach a healthcare or wellness website, and small practices frequently fall under more than one.
| Rule | Who it covers | Standard | Compliance date |
|---|---|---|---|
| ADA Title II, 28 CFR 35.200 | State and local governments, population 50,000 or more | WCAG 2.1 AA | April 26, 2027 |
| ADA Title II, 28 CFR 35.200 | Local governments under 50,000, and special district governments | WCAG 2.1 AA | April 26, 2028 |
| HHS Section 504, 45 CFR 84.84(b)(1) | HHS funding recipients with 15 or more employees | WCAG 2.1 AA | May 11, 2027 |
| HHS Section 504, 45 CFR 84.84(b)(2) | HHS funding recipients with fewer than 15 employees | WCAG 2.1 AA | May 10, 2028 |
| ADA Title III | Private businesses open to the public, including private practices | No adopted standard | Already in effect |
| ACA Section 1557, 45 CFR 92.204 | Covered health programs and activities | Accessible information and communication technology | Effective July 5, 2024 |
| If you take Medicare, Medicaid, or any other HHS financial assistance, the Section 504 rule reaches you. If you accept no federal money and run a cash-pay practice, you are a Title III business owner with an obligation that is already active and no deadline to wait for. |
What are the new ADA requirements for websites?
Both federal deadlines moved in 2026 and both moved by one year. DOJ published an interim final rule on April 20, 2026 at 91 Fed. Reg. 20902, pushing Title II compliance from April 2026 to April 26, 2027 and April 26, 2028. HHS followed on May 11, 2026, moving Section 504 to May 11, 2027 and May 10, 2028.
The accessibility standards did not change. The underlying Title III obligation did not change either, and it never had a deadline to extend. Treat the extension as schedule relief for budgeting, not as permission to defer your accessibility efforts.
WCAG 2.2 became a W3C Recommendation on October 5, 2023, with an editorial update on December 12, 2024. It adds nine success criteria and no regulator has adopted it yet. Aiming new builds at WCAG 2.2 Level AA is the current best practice because it is backward compatible with 2.1, and the new criteria, particularly minimum target size and accessible authentication, are the ones real users complain about.
What does an ADA compliant website look like?
An ADA compliant website looks almost exactly like a well-built site. Accessible design is not a visual style, it is a set of constraints on contrast, structure, interaction, and text alternatives. Most website elements that carry the work are invisible to sighted mouse users, which is why practices assume their site passes.
Why ADA compliant web design is not a style choice
Nothing in digital accessibility tells you to use a particular color, font, or layout. It tells you that whatever you choose has to survive a screen reader, a keyboard, and 400% zoom. Here is the working spec.
Proper color contrast
Body text needs a 4.5:1 color contrast ratio against its background, and text at 18.66px bold or 24px regular and larger needs 3:1 (SC 1.4.3). Maintaining sufficient color contrast is the single most common failure on practice websites, usually in light gray helper text under form fields and in muted button labels. For website visitors with visual impairments, this is the difference between reading your hours and leaving.
Interactive elements and meaningful graphics need 3:1 against adjacent colors (SC 1.4.11). That rule kills the thin-gray-border input field, which is why so many redesigns start there.
Never convey information through color alone. Required fields marked only in red, appointment availability shown only in green, and chart series distinguished only by hue all fail for users with color blindness and other visual disabilities. Add a shape, a label, or a pattern.
Legible fonts, design elements, and layout
Use legible fonts at a real size, keep line length reasonable, and let the page reflow. Content should work at 320px wide and at 400% zoom without horizontal scrolling. A layout built as one or two columns reflows cleanly, with secondary content stacking below the main column. A four-column dashboard does not.
Heading styles must reflect document structure, not font size. H1 once, then H2 and H3 in order, with no levels skipped. Semantic HTML is what carries that structure to assistive technology: real heading tags, real lists, real landmarks. Screen readers navigate by heading, and a page where everything is styled as a bold paragraph is a page with no navigation. Clear and consistent navigation across templates matters for the same reason, because users who cannot scan visually rely on the menu being in the same order on every page and on finding information in a predictable place.
Keyboard accessibility, navigation, and focus
Every interactive element must be reachable and operable with a keyboard alone, in a logical order, with a visible focus indicator. Test keyboard navigation yourself: tab through your contact page without touching the mouse. If focus disappears, if a dropdown traps you, or if the sticky header hides the focused element, you have a Level A failure.
Screen reader compatibility rides on the same markup. Native buttons, real labels, and correct ARIA roles are what assistive technologies read. WCAG 2.2 added SC 2.4.11, which requires that the focused element not be fully obscured by other content. Sticky headers and cookie banners are the usual culprits.
Forms and intake
Every input needs a programmatically associated label. Placeholder text is not a label, because it disappears on focus and typically fails contrast. Error messages must identify the field and describe the fix in text, not just turn the border red.
For intake forms, SC 3.3.7 on redundant entry and SC 3.3.8 on accessible authentication matter more than people expect, especially for patients with cognitive disabilities. Do not make someone re-enter information they already gave you, and do not gate a portal behind a puzzle CAPTCHA with no alternative. Offer multiple methods of contact so no one is stuck at a broken form.
Images and alternative text
Alt text describes the function of an image in its context. A headshot on a bio page gets the clinician’s name. A decorative background gets an empty alt attribute so screen readers skip it. A chart gets a short alt plus the underlying numbers in nearby text or a table.
The failure mode is not missing alternative text, it is useless alternative text. “image1.jpg” and “photo of office” both pass an automated checker and both tell a blind patient nothing.
Media, motion, and alternative formats
Video needs synchronized captions, audio needs a transcript, and anything that autoplays for more than five seconds needs a pause control. Nothing should flash more than three times per second. Captions and transcripts are the two highest-value additions most practice sites are missing, and publishing alternative formats of the same digital content, a transcript beside a video or an HTML version of a PDF intake packet, solves several criteria at once.
How do I make my website fully ADA compliant?
Work in this order. Each phase depends on the one before it, and skipping ahead is how practices pay twice.
- Audit against a real baseline. Run an automated scan with the right tools, then manually test keyboard operation, screen reader output, and zoom reflow on your five most important templates. Automated testing finds roughly a third of accessibility issues on its own, so automated audits always need manual testing beside them.
- Fix the templates, not the pages. Cost scales with unique templates, not with page count. A 200-page site built on six templates is a six-template job.
- Fix the content. Alt text, heading order, link text, PDFs, and captions. Accessible content is an ongoing content creation standard, not a one time project, and it is where your team keeps working after launch.
- Vet the third parties. Ask every embedded vendor, your scheduler, your payment form, your review widget, and any other platforms you rely on for a current Accessibility Conformance Report. No report means no evidence.
- Train the people who publish. Anyone who adds a page, uploads a PDF, or posts a photo needs 30 minutes on the WCAG guidelines that apply to their job. Most regressions after launch come from content, not code.
- Publish an accessibility statement with a working contact method, and name an owner who reviews it quarterly to ensure accessibility holds as the site changes.
How can I tell if a website is ADA compliant?
You cannot tell from a scan alone. Automated checkers verify machine-testable criteria like contrast values and missing attributes, which is a real but partial slice of WCAG. The rest, including whether your alt text is meaningful and whether your tab order makes sense, requires a person.
Automated testing versus user testing
A five-minute manual check catches most of what matters on a practice site: tab through the page, zoom to 400%, turn on your operating system’s screen reader and listen to the first 30 seconds of your homepage, and submit your contact form with a deliberate error. Formal user testing with real users who rely on assistive technologies daily catches the rest, and it is the only method that tells you whether the site is usable rather than merely conformant.
What are some examples of websites that are ADA compliant?
No website is formally certified, so treat any “ADA compliant website examples” list skeptically. What you can study are organizations that publish their own conformance work: ada.gov, section508.gov, and the W3C Web Accessibility Initiative.
What an accessible website has in common
Look at how those sites structure headings, label forms, and handle focus. The pattern worth copying for a practice is boring: a single-column content layout, high-contrast text, visible focus rings, labeled forms, and real alt text. Accessible web design on a therapy or clinic site should be indistinguishable from good custom web design, and many of the same technical choices that support accessibility also enable advanced, holistic SEO techniques.
How much does it cost to make my website ADA compliant?
There are three paths, and they are not interchangeable.
| Approach | What it is | What it fixes | What it misses | Legal standing | Cost shape |
|---|---|---|---|---|---|
| Overlay widget | A JavaScript script that modifies the page in the browser | Some contrast and text-size preferences | Keyboard traps, form labels, heading structure, alt text quality, PDFs | Weak. Overlays have been named in website accessibility suits rather than preventing them | Recurring subscription, forever |
| Audit and remediate | Manual and automated audit, then fixes to your existing templates | Most WCAG 2.1 AA failures in the current build | Nothing structural, but regressions return with each new feature | Strong, if documented | One-time project, scaled by template count, plus maintenance |
| Accessible rebuild | New build with accessibility in the design system | Everything, and prevents regressions | Nothing, if the component library is tested | Strongest | Project cost, no accessibility premium if specified upfront |
| The honest answer on budget is that cost tracks unique templates and PDF count, not page count. Building websites with accessibility in the spec from day one costs close to nothing extra and prevents the expensive fixes later. Retrofitting costs real money. We break down what drives project pricing on our custom web design page. |
Overlays deserve one more line. They are marketed to small practices as a one-click fix for legal compliance. They do not fix the underlying code, they frequently interfere with the assistive technology a user already has configured, and buying one does not move the legal consequences to the vendor.
How accessible design helps you get found
Accessible design and search performance pull in the same direction. Semantic heading structure, descriptive link text, real alt text, captions and transcripts, and fast reflowing layouts are all things screen readers and crawlers both depend on. Transcripts in particular give you indexable text where you previously had none, which matters for both local SEO and for broader SEO strategy for small practices, and for getting quoted in AI search answers as Google’s AI-driven search experience continues to evolve.
Accessibility also widens the audience that can actually use the site once they land, which is the part most practices underestimate. This is not the reason to do the work. It is the reason it is easier to justify.
Where to start
Pick your five highest-traffic templates, tab through each one, and write down what breaks. That list is your scope. If your practice takes HHS funding and has 15 or more employees, your date is May 11, 2027, and a retrofit of a mature digital presence is not a four-week project, especially if you also want to pair accessibility work with rapid URL indexing strategies so compliant content is visible quickly.
We build accessibility into every site we design for clinicians and wellness practitioners. If you want a specific read on where your current site stands, see our website design for health and wellness practitioners.
