Dental practices are one of the most frequently-named business categories in ADA Title III accessibility lawsuits. This isn’t hypothetical: search “dental practice ADA lawsuit” and you’ll find years of settlements against practices whose websites weren’t accessible to users with disabilities. The plaintiffs’ bar has specifically targeted small and mid-sized medical and dental practices because the settlements are predictable and the practices usually settle rather than litigate.
The good news: the fix is technical, well-documented, and adds trivial cost to a properly-built website. The bad news: most dental practice websites in the wild fail multiple WCAG 2.1 AA criteria, and if your website is more than three years old, it almost certainly does.
This post covers what the standard actually requires, what the common failures look like, how to test your own site, and what a competent web developer should be delivering.
What the ADA actually requires
The Americans with Disabilities Act, Title III, covers places of public accommodation. Court decisions over the past decade have consistently held that websites providing services to the public are covered by Title III — a dental practice’s website that provides information about services, allows appointment booking, or accepts patient communication is treated the same as the physical office for ADA purposes.
The ADA itself doesn’t specify technical requirements for websites. Instead, courts and the Department of Justice have consistently pointed to WCAG 2.1 Level AA as the practical compliance standard. Meeting WCAG 2.1 Level AA is what “ADA compliance” means for a website in the current legal environment.
What WCAG 2.1 Level AA requires
WCAG (Web Content Accessibility Guidelines) is organized around four principles: content must be Perceivable, Operable, Understandable, and Robust. Level AA is the middle of three conformance levels and is the practical target for commercial websites.
The specific requirements are technical, but the ones that most commonly trip up dental practice websites:
Text alternatives for images. Every meaningful image needs an alt attribute describing what it shows. A photo of your doctor needs alt text like “Dr. Sarah Chen, DDS” — not blank, not “IMG_2847.jpg”, not “photo.”
Color contrast. Text must have sufficient contrast against its background. Body text needs a contrast ratio of at least 4.5:1. That fashionable light-gray-on-white color scheme most dental websites still use? Almost always failing.
Keyboard navigability. Every function on the site — every link, form, menu, video control — must be operable using only a keyboard. Users who can’t use a mouse rely on this. Fancy dropdown menus that only work on hover are a common failure.
Real form labels. Every form field needs a real <label> element, not just placeholder text. Screen readers announce labels; they don’t reliably announce placeholder text. Contact forms with only placeholder text (“Your Name…”) are a common failure.
Semantic HTML. Headings must be actual <h1> through <h6> elements, in order. Links must be <a> elements. Buttons must be <button> elements. Fancy JavaScript-based interactive elements that skip semantic HTML are a common failure.
Focus states. When a keyboard user tabs through the page, the currently-focused element must be visually indicated. Many modern dental practice websites disable focus outlines for aesthetic reasons, which breaks keyboard navigation for anyone who relies on it.
Video captions. If your site has video content — like a “meet the doctor” video — it needs captions. Auto-generated captions from YouTube are typically sufficient for WCAG AA; no captions at all is not.
Consistent navigation. The navigation menu should be consistent from page to page, so users who memorize their way around your site can rely on that.
Text resize. Users must be able to resize text up to 200% without content breaking. Fixed pixel sizes that don’t scale are a failure.
Error identification. When a user submits a form with an error (missing required field, invalid email format), the error must be clearly identified in text — not just a red border, not just a color change.
There are more, but those cover the majority of dental practice website failures we see.
Why dental practices specifically get sued
A few reasons the plaintiffs’ bar targets dental practices:
Small enough to settle, large enough to pay. Most dental practices don’t have the legal budget to fight a Title III lawsuit through discovery and trial. Settlement is cheaper. Plaintiffs’ firms have industrialized this.
High visibility, easy to find. Dental practice websites are heavily indexed, easy to identify by location, and easy to scan for common failures.
Regulated healthcare business. Practices in healthcare adjacencies are held to higher public-accommodation expectations than, say, a hobbyist’s personal blog.
Template-driven websites with common failures. Many dental practice websites are built on the same handful of templates from the same handful of vendors, and those templates often have the same accessibility failures. A plaintiff’s firm can identify targets efficiently.
How to test your own site
You don’t need to hire an auditor to catch the majority of issues. A few free tools:
axe DevTools (Chrome extension). Free, runs in the browser, gives you a specific violation list with links to explanations. This is the tool most professionals use for first-pass testing.
Lighthouse Accessibility Audit. Built into Chrome DevTools. Not as thorough as axe but catches the highest-severity issues.
WAVE (WebAIM). Free browser extension. Visual overlay showing accessibility issues on the page.
Keyboard test. Unplug your mouse. Try to use your website with just the Tab, Shift+Tab, Enter, and arrow keys. Try to book an appointment. Try to submit the contact form. Note every place you get stuck.
Screen reader test. VoiceOver is built into macOS (Cmd+F5 to toggle) and iOS (in Settings > Accessibility). NVDA is free on Windows. Turn one on and try to navigate your site. This is uncomfortable but revealing.
Run these on your homepage, your services pages, your contact page, and your appointment booking flow. If you find dozens of issues, you’re normal for a dental practice website. If you find zero, either the tool didn’t load or your site was built by someone who actually cares about accessibility.
What a competent web developer should deliver
A dental practice website built to modern standards should be shipping WCAG 2.1 Level AA out of the box. This means:
Semantic HTML by default. Real headings, real buttons, real labels, real navigation elements.
Accessible color palette from the design phase. Contrast ratios verified before the site is built, not audited after. Your brand colors should be chosen (or adjusted) to pass AA at body text size.
Keyboard-navigable from first commit. Focus states preserved, tab order logical, all interactions available via keyboard.
Alt text discipline. Every image gets meaningful alt text, not filler.
Accessibility testing as part of the launch checklist. axe-core runs in the build pipeline, manual keyboard and screen reader spot checks before launch, not as a post-launch “phase two.”
Ongoing testing on updates. When content changes or new pages are added, accessibility is re-verified. This is part of what a monthly retainer should cover.
If your current vendor is doing none of this, your site is almost certainly failing WCAG AA. This isn’t a moral failing on your part — you hired someone to build a website, and they didn’t build one that meets current standards. But it’s a real legal exposure and it’s worth fixing.
What we do at Militech
Every website we build for a dental practice meets WCAG 2.1 Level AA at launch, verified with axe-core (automated) and manual assistive-technology testing (keyboard-only navigation and screen reader spot check on VoiceOver and NVDA). Accessibility is on the launch checklist, not a post-launch consideration.
On monthly retainers, accessibility is re-verified whenever content or template changes are made. If you take our engagement and add a new page yourself through the CMS six months later, we’d want to know so we can spot-check it.
We’re not accessibility auditors and we don’t sell VPAT reports — but we build to the standard, and we can point to specific test artifacts if you ever need to document compliance.
If you’ve already been contacted
If your practice has already received a demand letter or complaint alleging ADA violations, the first step is a real accessibility audit — either from a specialized firm or from your web developer. Second step is remediation. Third step is a settlement or defense strategy, which is a conversation for your attorney, not for us.
Don’t ignore the letter. Don’t send a defensive response. Talk to counsel first.
Building or rebuilding a dental practice website? Ask us directly about accessibility. Contact us and we’ll walk through what a compliant build looks like for your practice. See our dental practice services page for the full offer.