Does my dental website need to be ADA accessible?

What the DOJ guidance means for a practice

The DOJ's March 18, 2022 guidance places businesses open to the public under Title III of the ADA. It names hospitals and medical offices as examples. DOJ says it has consistently treated goods and services offered online as part of those businesses' ADA duties. See the DOJ guidance and sample enforcement cases.

For private businesses, that guidance says DOJ has no regulation setting detailed technical website standards. Businesses have flexibility in how they meet their duties, but they still must comply. It points to WCAG and the Section 508 Standards as helpful guidance.

The page also flags separate 2024 rules for state and local governments under Title II. Private practices fall under Title III. Ask your own counsel about your obligations and any accessibility complaint. Neither this article nor a website scan can assess your legal exposure.

Use WCAG as a clear build target

WCAG stands for Web Content Accessibility Guidelines. WCAG 2.2 is the current W3C version. Read the W3C overview for context and the WCAG 2.2 standard for the technical reference.

When hiring a developer, ask for the version and level in writing. For a WCAG 2.2 AA project, ask which pages, forms, documents, and booking screens the review will cover. Ask who will handle problems in tools supplied by another vendor.

Request a written list of checks, findings, and fixes. Have the developer show you how a patient completes a booking request with a keyboard. Ask your attorney what the agreed technical target means for your practice's legal duties.

Check the path from homepage to booking

Use the following checks to record questions for your developer. Start on the homepage and follow the same steps a new patient would take. Include any booking screen that opens on another site. These checks are a starting point, not a full accessibility review.

1. Use only the keyboard. Put the mouse aside. Use Tab and Shift+Tab to move through links and controls. Try opening the menu, choosing an office, and reaching the booking form. Note any point where you get stuck or cannot tell which control is selected.
2. Zoom to 200%. Enlarge the page in your browser. Check that you can still read the text and use the menu, form fields, and booking button. Record text that overlaps, gets cut off, or hides a control.
3. Check form labels and errors. Read each field's label and instructions. In a test arranged with your developer, leave a required field empty or enter an invalid value. Check whether the error explains what to fix. Ask the developer to verify labels and error alerts with a screen reader.
4. Review doctor photo alt text. Ask your developer to show you the text alternative for each doctor photo. Check that it conveys the image's purpose in context. Flag missing or unhelpful descriptions for review.
5. Watch videos with captions. Turn off the sound and turn on captions. Check that the spoken information is covered and the words make sense. Include welcome videos and treatment videos.
6. Check contrast and color cues. Ask your developer to measure text contrast. Look for faint text on pale backgrounds. Check that required fields and errors have words or other cues, rather than color alone.
7. Open PDF forms. Download the forms patients are asked to use. Try reading and moving through them with a keyboard. Ask for a document accessibility review, including screen reader checks. List any form you cannot complete.

For each problem, save the page address, the step you tried, and what happened. Use the dentist website checklist to help decide which pages and patient tasks to include.

Pair automated tools with manual checks

DOJ says automated checkers and overlays can help, but they require care. A clean report does not prove that everything is accessible. Its guidance recommends pairing automated checks with manual review.

If your site has an accessibility widget, ask what it does and what still needs testing. Ask the developer to demonstrate the booking path and form errors. Review the actual patient tasks alongside the tool's report.

When you receive a scan, ask which pages it checked. Were the intake documents included? Did anyone test the booking screens? Ask for a separate list of manual checks and any unresolved findings. Keep both lists with the project records so the next review can start with clear questions.

Give patients a way to report problems

DOJ suggests giving the public a way to report accessibility problems. Include clear contact details for that purpose. Decide who at the practice will read those reports and send them to the person who can make repairs.

Ask for the page address and a description of the blocked task. Keep a work list with the reported issue, the person handling it, and the result of the follow-up check. Ask your developer to test the same task after each repair.

When adding a new form, photo, video, or booking tool, include it in your review plan. Also keep the dental website HIPAA guide on your reading list. Bring legal questions about either topic to your own counsel.

How WTM handles accessibility

We build to WCAG 2.2 AA and put that in writing in the agreement. That is the standard we build and test to. It is not a legal certification, and it cannot stop someone from filing a claim. Your own attorney should advise on your legal duties.

Founder Ray Hussain leads every project. We write the page copy as part of the price, and you get one year of support after launch. You own the site, code, content and domain. See our dental website design page for the rest.

Put the checks in your next quote

Bring your self-check notes to your developer and ask for a written scope covering the standard, testing, and repairs. Use the website quote comparison tool to review proposals.