The twelve checks
These are ordered by how often we find them broken on dental practice websites. The first five account for the overwhelming majority of violations in our audit data — and they are also the ones automated plaintiff-side scanners flag first.
| # | Check | WCAG criterion | The dental-site version of the problem |
|---|---|---|---|
| 1 | Every meaningful image has alt text | 1.1.1 (A) | Smile galleries, before/after photos, team headshots, and service icons shipped with empty or filename alt text |
| 2 | Text contrast is at least 4.5:1 | 1.4.3 (AA) | Soft teal, seafoam, and light-gray text on white — the default dental template palette — usually lands near 2.5:1 |
| 3 | The whole site works by keyboard alone | 2.1.1 (A) | Appointment widgets, mega-menus, and photo sliders that need a mouse; keyboard users can’t book at all |
| 4 | Keyboard focus is visible | 2.4.7 (AA) | Templates that set outline:none so the design looks "clean" — sighted keyboard users navigate blind |
| 5 | Every form field has a real label | 3.3.2 (A) / 1.3.1 (A) | Contact and appointment-request forms using placeholder text as the only label; screen readers announce nothing |
| 6 | Link text says where it goes | 2.4.4 (A) | "Click here" and "Learn more" repeated for every service page |
| 7 | Videos have captions | 1.2.2 (A) | Practice-tour and testimonial videos with no caption track |
| 8 | Headings are structured, not styled | 1.3.1 (A) | Bold paragraph text used as visual headings; screen-reader users lose the page outline |
| 9 | The page declares its language | 3.1.1 (A) | Missing lang="en" — screen readers may mispronounce the entire site |
| 10 | The site survives 200% zoom and reflow | 1.4.4 / 1.4.10 (AA) | Fixed-width layouts that clip the booking form when low-vision patients zoom |
| 11 | Motion can be paused | 2.2.2 (A) | Auto-rotating hero carousels with no pause control |
| 12 | Patient PDFs are accessible (or have HTML equivalents) | 1.1.1 / 1.3.1 (A) | Scanned intake forms posted as image-only PDFs — invisible to screen readers |
How to actually run this checklist
The five-minute manual pass. Put your mouse away. Press Tab repeatedly from the top of your homepage: can you see where you are at every step, reach every menu item, open the booking form, fill it, and submit it? Then watch any video on your site with the sound off — are there captions? Those two tests alone cover checks 3, 4, 7, and 11.
The technical pass. Contrast ratios, alt attributes, form-label markup, heading structure, and language declarations live in the code, and eyeballing them is unreliable — a color pair can look fine and still measure 3:1. This is what automated engines are for: axe-core, Lighthouse, and WAVE each test these criteria programmatically, and cross-referencing all three catches what any single engine misses.
The judgment pass. Automation confirms alt text exists; it cannot confirm the alt text is useful. "IMG_4321.jpg" passes a naive check and fails a patient. This is the layer where an AI-assisted review or a human evaluator reads the page the way a screen-reader user would.
Why these twelve and not all fifty criteria
WCAG 2.1 AA has 50 success criteria, and full conformance means meeting all of them. But violations are not evenly distributed: WebAIM’s annual survey of one million home pages finds the same handful of failure types — low-contrast text, missing alt text, missing form labels, empty links — on the vast majority of failing pages. Dental sites follow the same pattern, with the booking flow as the highest-stakes surface: it is the thing a patient with a disability most needs to use, and the thing plaintiffs’ firms test first.