All industries » Dental practice website accessibility
Dental practice website accessibility: WCAG 2.1 AA on ProSites, PBHS, Officite, custom WordPress
Dental practice websites are subject to ADA Title III as commercial public accommodations. Practices that accept Medicaid (or any state-funded dental program) are additionally covered by ACA Section 1557 and must meet WCAG 2.1 Level AA under the HHS May 2024 final rule. Even purely private-pay practices fall under the federal ADA Title III framework that Robles v. Domino's established. The dental-CMS landscape is narrower than general healthcare: ProSites, PBHS, Officite, and SmileMarketing are the main dental-specific platforms, with custom WordPress and Squarespace common at independent practices. Site Brace audits any dental practice for $149 flat.
Short answer: the highest-risk surfaces on a dental practice site are the before-and-after photo galleries (often Lightbox or modal-based with inaccessible controls), insurance verification forms, appointment scheduler iframes, downloadable HIPAA notices and patient intake forms, and the doctor bio pages. Color contrast on appointment-CTA buttons, missing alt text on dental photography, untagged PDFs, and unlabeled form fields account for the bulk of findings. Practices accepting Medicaid add Section 1557 exposure on top of the baseline ADA Title III. Site Brace audits up to 25 pages for $149 flat. Try a free single-page check on your homepage first.
The rules that apply to dental practices
1. ADA Title III (always applies)
The Americans with Disabilities Act Title III applies to any practice with a physical office that markets and accepts patients through its website. The 9th Circuit Robles v. Domino's precedent is the canonical authority and has been cited in dental cases across multiple circuits. The dental industry has been a steady target for ADA Title III plaintiff-side firms because the structural pattern (small practice, customer-facing website, photo-heavy marketing) is consistent and the entities are too small to fight cases past the demand-letter stage.
2. ACA Section 1557 (if accepting Medicaid)
If your practice accepts Medicaid (or CHIP, or state-administered dental programs receiving federal funds), you are a Section 1557 covered entity. The HHS May 2024 final rule explicitly names WCAG 2.1 Level AA as the conformance standard for covered-entity web content and mobile apps. The compliance deadline is May 2026 for most covered entities. HHS Office for Civil Rights enforces; complaints can trigger Corrective Action Plans or, in serious cases, withholding of federal funds.
Purely private-pay practices (cash, in-office membership plans, dental insurance only) are subject only to Title III, not Section 1557. Most US dental practices accept some Medicaid; assume Section 1557 applies unless you have explicitly confirmed otherwise.
3. State laws
State human-rights and accessibility laws (California's Unruh Act, NY's Human Rights Law, the PA Human Relations Act, etc.) apply to dental practices the same as to any other business. See the relevant state Title II guide for the public-entity dynamics, but private dental practices fall under the state-law equivalents of ADA Title III rather than Title II.
The high-risk surfaces specific to dental sites
Before-and-after photo galleries
Dental practices market heavily through before-and-after photography (cosmetic, orthodontic, implants, full-mouth reconstruction). Two common patterns fail:
- Lightbox or modal galleries where clicking a thumbnail opens an enlarged image. Many implementations trap keyboard focus, hide focus indicators, or fail to label the close button.
- Hover-to-reveal "before" vs "after" slider widgets that show the reveal on mouse-hover but provide no keyboard interaction or screen-reader description of the transformation.
The fix is either to use an accessible gallery component (the dental-CMS vendors have varying support) or to provide each before-and-after pair as two separate captioned images.
Insurance verification and patient intake forms
"Verify my insurance" forms ask for SSN, insurance ID, group number, date of birth, and dependent information. They are some of the longest forms on the site and often the worst-labeled. Patient-intake forms (medical history, medication list, allergy list) are even longer. Most are built in dental-CMS form builders that style placeholder text as the label, leaving screen-reader users unable to determine what each field expects.
Appointment scheduler iframes
Many dental sites embed third-party scheduling iframes (NexHealth, LocalMed, RevenueWell, Solutionreach). The practice is responsible for the rendered experience even when the underlying widget is third-party. Iframes without titles are an axe-core failure (frame-title) that visitors using screen readers cannot navigate.
What we typically find on a dental practice website
| Finding | axe-core rule | Typical cause |
|---|---|---|
| Before-and-after gallery has keyboard trap or missing labels | Manual finding | Lightbox or hover-slider widget built without accessibility |
| Insurance verification form fields have no labels | label |
Dental-CMS form builder styles placeholder text as the label |
| Downloadable patient intake or HIPAA forms not tagged for screen readers | Manual finding (PDF interior) | PDFs exported from Word without accessibility tagging |
| Appointment scheduler iframe lacks accessible name | frame-title |
NexHealth, LocalMed, RevenueWell, or Solutionreach widget embedded without title |
| Color contrast on appointment CTA buttons and "Call now" stickies | color-contrast |
Practice brand colors (often pastel blue or teal) that fail 4.5:1 against white |
| Doctor photo on bio page has no meaningful alt text | image-alt |
CMS auto-populates alt from filename (often "dr-smith-headshot.jpg") |
| "Services" navigation icons used as link targets without text | link-name |
Icon-only navigation tiles for service categories |
| aria-label on generic elements | aria-prohibited-attr |
Dental-CMS theme customizations or accessibility-overlay injection. See aria-label on a div. |
Notes on dental-CMS platforms
ProSites and PBHS
The two dominant dental-specific website platforms. Both ship template designs that vary in baseline accessibility; older templates tend to be heavier on accessibility debt (color contrast, generic ARIA misuse) than recently-released templates. Vendor support for accessibility fixes varies; the practice is the responsible party regardless of vendor effort.
Officite, SmileMarketing, RevenueWell, and other dental marketing companies
These vendors run sites for thousands of practices on shared platforms. A platform-level accessibility issue affects every customer's site simultaneously. Fixes therefore depend on the vendor's roadmap; practices on these platforms have less control over per-site remediation than on a custom-WordPress site.
Custom WordPress
Independent practices on custom WordPress have the most control over per-site fixes but also the most accessibility debt because the theme was usually built by a small marketing agency without accessibility expertise. WordPress accessibility plugins often make things worse by adding aria-label on generic elements (the aria-prohibited-attr issue).
Why overlays are a poor fit for dental practices
Accessibility overlays are heavily marketed to dental practices through dental-marketing publications. We have written about why accessibility overlays do not actually make sites WCAG-compliant in detail. For dental specifically:
- Overlays do not touch downloadable PDFs (the HIPAA notice, the patient intake forms - all covered by Title III and Section 1557).
- Overlays do not reach inside iframes (the appointment scheduler, the most-interacted element on the site).
- Section 1557 is a substantiation regime; HHS Office for Civil Rights can request evidence of WCAG conformance and an overlay subscription is not evidence.
- The FTC's $1 million settlement with accessiBe in April 2025 makes overlay compliance claims a documented liability.
How Site Brace audits a dental practice website
The standard page mix for a dental practice audit:
- Homepage
- Doctor bio pages (1 per doctor, typically 1-4 doctors for a small practice)
- Services pages (cosmetic, orthodontic, implants, restorative, pediatric, etc. - top 4-6)
- Before-and-after gallery
- Appointment scheduling page (includes the embedded scheduler iframe)
- Insurance and financing page (includes the verification form)
- Patient forms page (where downloadable intake PDFs are linked)
- HIPAA notice page
- Contact, location, hours
- Accessibility statement (if one exists)
That mix covers up to 25 pages for a typical 1-4 doctor practice. The audit runs axe-core 4.10 against each page, captures element-level screenshots of every contrast failure, and packages the findings into a written report with copy-paste fix code and 12 re-scans included over 12 months.
Pricing is $149 flat, one-time. To see what the report looks like, view a sample report we built for a fictional family-medicine clinic. The dental findings are similar in shape (forms, photos, bios) even though the clinical content is different.
Want to check your own site first? Run a free single-page check on your homepage or your appointment scheduling page - one URL, about a minute, no signup needed to see the result.
Start a dental practice website audit, $149
Related:
- Healthcare website ADA compliance - the broader healthcare framework (Section 1557 details apply to dental practices accepting Medicaid)
- Free single-page WCAG check
- Why accessibility overlays do not make sites WCAG-compliant
- axe-core vs WAVE vs Lighthouse
- aria-label on a div: why screen readers ignore it