The no-panic guide to WCAG compliance
If you accept Medicare or Medicaid, your practice generally falls under HHS’s web accessibility rule, which sets WCAG 2.1 Level AA as the standard (subject to some exceptions). You don’t need to rebuild your entire site. You need a clear plan and the right places to start.
On May 7, 2026, HHS issued an Interim Final Rule extending the Section 504 web accessibility compliance deadlines by one year. Recipients with 15 or more employees now have until May 11, 2027. Recipients with fewer than 15 employees now have until May 10, 2028. The legal obligation remains in full effect. Only the deadline has shifted. Source: HHS Office for Civil Rights, May 7, 2026.
Key takeaways
- The deadline shifted, not the obligation. HHS extended compliance to May 2027 (15+ employees) or May 2028 (under 15 employees), but the legal requirement is still in full effect.
- WCAG 2.1 Level AA is a specific, testable benchmark. It is not a vague suggestion. Automated tools only catch 30–40% of issues, so manual testing is required.
- Coverage extends beyond your own code. Web content and mobile apps you provide directly, or through a vendor, contract, or license, are covered. The rule includes specific exceptions, so check what applies to your setup.
- Accessibility overlays are not a shortcut. Automated widgets cannot guarantee WCAG compliance on their own and can introduce new barriers. They’re not a substitute for real fixes.
- You can do this in stages. Start with an audit, fix color contrast and alt text first, then build systems to stay compliant over time.
If you accept Medicare or Medicaid, your practice generally falls under HHS’s Section 504 web accessibility rule. Under the current timeline, recipients with 15 or more employees have until May 11, 2027, and smaller recipients have until May 10, 2028. That might sound stressful. But here’s the truth: WCAG compliance for therapists doesn’t have to be overwhelming.
I’ve been building accessible therapy websites since before it was mandated. Not because it looked good on paper, but because it’s the right thing to do. Your clients with ADHD, visual processing differences, or motor challenges deserve a website that actually works for them. The new HHS ruling just makes it official.
The rule includes specific exceptions and limitations, including for certain archived content, some third-party social media posts, and cases of undue burden, so a licensed attorney should confirm exactly how it applies to your practice. What follows is the practical baseline that applies to nearly every private practice website: WCAG 2.1 Level AA.
The good news? You don’t need to rebuild your entire site from scratch. You need a clear plan, the right support, and a way to check your work without spiraling. That’s what this guide covers.
What is WCAG 2.1 Level AA?
WCAG stands for Web Content Accessibility Guidelines. It’s a set of standards created by the World Wide Web Consortium (W3C) to make websites usable for people with disabilities.
Version 2.1 is what the HHS ruling requires. (There’s a newer 2.2 version, but the legal standard is still 2.1 for now.) Level AA is the middle tier of compliance. It includes essential features like captions for videos, keyboard navigation, and proper color contrast.
Think of WCAG compliance as building a ramp instead of stairs. It helps people who need it, and it makes things smoother for everyone else too.
The four principles of web accessibility
WCAG is built on four core principles. They’re nicknamed POUR: Perceivable, Operable, Understandable, Robust. Here’s what they mean in plain terms.
Perceivable: Your content needs to be available in multiple formats. That means alt text for images, captions for videos, and layouts that adapt to different screen sizes. If someone can’t see an image, they should still know what it shows. If someone can’t hear your video, they should still get the information.
Operable: People need to navigate your site without a mouse. That includes keyboard-only users and people using assistive devices. It also means avoiding things like flashing images that could trigger seizures. Your site should be usable no matter how someone interacts with it.
Understandable: Your content should be clear and predictable. Use plain language instead of jargon. Make your navigation consistent across pages. If someone makes a mistake on a form, tell them what went wrong and how to fix it. Don’t make people guess.
Robust: Your site needs to work with current and future assistive technologies. That means clean code, proper HTML structure, and compatibility with screen readers. As technology evolves, your site should still be accessible.
These aren’t abstract concepts. They’re practical design choices that make your site work better for everyone.
Step 1: Audit your current site
You can’t fix what you don’t know is broken. Start with a comprehensive accessibility audit.
Use automated tools first. Tools like Lighthouse, WAVE, or axe DevTools can scan your site and catch obvious issues like missing alt text or color contrast problems. They’re free, fast, and helpful for spotting patterns.
But here’s the catch: automated tools only find about 30–40% of accessibility issues. They can’t test things like keyboard navigation flow, how well your forms handle errors, or whether your content makes sense to screen reader users.
That’s why you need manual testing. If you have the budget, hire a third-party accessibility expert to audit your site. They’ll test with real assistive technology and give you a prioritized list of what to fix first.
If you’re doing this yourself, test your site with:
- Keyboard-only navigation (unplug your mouse and try to complete key tasks)
- A screen reader like NVDA (free for Windows) or VoiceOver (built into Mac)
- Browser zoom set to 200% to check if text stays readable
Don’t forget your third-party tools. If you use a chatbot, scheduling widget, or embedded forms, those need to be accessible too. You’re responsible for everything on your site, even if someone else built it.
Step 2: Update your digital platforms
Once you know what’s broken, it’s time to fix it. Here are the most common updates therapy websites need:
Add alt text to every meaningful image. Alt text is a short description that screen readers announce when someone can’t see the image. WCAG doesn’t set a character limit. The goal is the most concise description that still serves the image’s purpose, so describe what’s useful about the image, not just what it shows. “Therapist in a bright office” is okay. “Calm, welcoming therapy office with natural light” is better if the vibe matters. Purely decorative images, like background patterns or dividers, should use an empty alt attribute instead.
Fix your navigation. Make sure people can use your site with just a keyboard. That means logical tab order, visible focus indicators (so you can see where you are on the page), and skip links that let people jump past repetitive content. Test this yourself by tabbing through your site.
Add captions and transcripts. If you have videos on your site, they need captions. If you have audio content, provide a text transcript. YouTube’s auto-captions are a decent starting point, but edit them for accuracy. This helps people who are deaf or hard of hearing, and it also helps people who prefer to read or who are in a noisy environment.
Check your color contrast. Text needs to have enough contrast against its background to be readable. WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Use a free tool like the WebAIM Contrast Checker to test your colors. If your text is hard to read, change the color or add a darker background.
Clean up your code. This one’s more technical, but it matters. Your site needs proper HTML structure: a logically nested heading order (generally H1, then H2, then H3), semantic markup (using the right tags for the job), and ARIA labels where needed. WCAG doesn’t ban every skipped level, but nesting headings logically makes your content much easier for screen reader users to scan. If you didn’t build your site yourself, work with your developer on this.
Not sure where to start? Fix color contrast and alt text first. Those have the biggest impact and are relatively quick to update.
Step 3: Train your team
Accessibility isn’t a one-time project. It’s an ongoing practice. If you or anyone on your team adds content to your site, they need to know how to keep it accessible.
Create simple documentation. Write down your accessibility standards in plain language. Include:
- How to write good alt text
- When to use headings and how to structure them
- How to check color contrast before publishing
- What to do if someone reports an accessibility issue
Keep it short. One page is better than ten. You want something people will actually reference.
Set up a process for accessibility requests. If a client or visitor reports a barrier, you need a clear way to respond. Designate one person (probably you, if you’re solo) to handle these requests. Document what was reported, what you fixed, and when.
Build it into your workflow. Before you publish new content, run through a quick accessibility check. Does the page have a clear heading structure? Are there any images without alt text? Can you navigate the page with a keyboard? This takes five extra minutes and prevents problems down the line.
If you’re working with contractors or third-party vendors, add accessibility requirements to your contracts. Make it clear that any content they create needs to meet WCAG 2.1 Level AA standards.
Step 4: Monitor and maintain
Websites change. You add new pages, update content, install plugins. Each change is a chance to accidentally break something.
Set up regular monitoring. Use automated tools to scan your site monthly. Lighthouse is built into Chrome DevTools and takes about two minutes to run. It won’t catch everything, but it’ll flag new issues before they become problems.
Do manual checks quarterly. Every three months, spend 30 minutes testing key user paths with a keyboard and screen reader. Can someone still book a consultation? Can they find your contact info? Can they read your blog posts? If something’s broken, fix it.
Stay current with guidelines. WCAG 2.2 is already out, and W3C is developing WCAG 3.0, a broader successor that’s still an early working draft. You don’t need to panic about every update, but keep an eye on what’s changing. The W3C website publishes updates and resources for free.
This doesn’t have to take over your life. You’re building a habit, not adding a second job. No fixed testing schedule can guarantee ongoing conformance on its own, since that depends on your specific content and changes. But consistent, recurring checks meaningfully lower the risk that your site drifts out of compliance, and they give your clients a better experience along the way.
What accessibility looks like in practice
WCAG 2.1 Level AA can feel abstract until you see it applied to a real therapy website. Here’s what the most common issues look like in practice and exactly what to do about each one.
Color contrast failures
Many therapy websites use light gray text on white backgrounds because it looks clean and minimal. The problem is that WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for normal-sized text and 3:1 for large text (18pt or 14pt bold). Light gray on white typically fails this test by a wide margin, making content unreadable for people with low vision or color processing differences.
The fix: use the free WebAIM Contrast Checker to test every color combination on your site. If your body text is failing, switch to a darker gray or black. If your branded accent color fails when used as text, use it only for decorative elements and ensure text placed on top of it has sufficient contrast with its background.
Missing or inadequate alt text
Alt text is the short description that screen readers announce when someone can’t see an image. In our experience auditing therapy websites, inconsistent alt text is one of the most common gaps we find. The rule of thumb: describe what’s useful about the image from the perspective of someone who can’t see it. For a photo of your therapy office, “Therapist in a bright office” is barely adequate. “Calm, sunlit therapy office with two comfortable chairs and a small plant by the window” gives the reader an actual sense of the space, which is relevant when they’re deciding whether to visit you.
Decorative images, like background patterns, separator lines, and purely aesthetic dividers, should have empty alt text (alt=””) so screen readers skip them entirely. Images that contain text (like a banner with your practice name) need alt text that includes that text exactly.
Keyboard navigation that doesn’t work
Not all users navigate with a mouse. Keyboard users tab through interactive elements: links, buttons, form fields. If your site isn’t fully keyboard-navigable, you’re failing one of WCAG’s core requirements. You’re also excluding a significant portion of your potential clients.
Test this yourself: unplug or disable your mouse and try to navigate your entire website using only the Tab, Enter, and arrow keys. Can you reach your contact form? Can you submit it? Can you navigate your menu? If the answer to any of these is no, your site has keyboard navigation failures that need to be fixed at the code level. If you use a WordPress or Squarespace theme, check whether there’s an updated version that addresses accessibility issues.
Forms that don’t label their fields
Your contact form might look fine visually. But if the form fields use placeholder text instead of proper HTML labels, screen reader users encounter fields with no announced context. They literally cannot tell what to type where.
The fix: ensure every form input has an associated <label> element that persists even after the user starts typing. Placeholder text disappears the moment someone starts filling in the field. A placeholder is a hint, not a label. Your developer or your form plugin should support proper label markup. Don’t assume any given platform is accessible by default. Test your specific form setup with a screen reader before you rely on it.
Third-party tools that are your responsibility
One of the most important clarifications in the HHS rule: if a tool is embedded on your website, it’s your accessibility responsibility, even if you didn’t build it. Your scheduling widget, your chatbot, your telehealth intake portal. All of it needs to meet WCAG 2.1 Level AA if you accept Medicare or Medicaid. Before renewing your contracts with these vendors, ask them for a current, completed Accessibility Conformance Report (ACR), the document commonly produced using the Voluntary Product Accessibility Template (VPAT). If they don’t have one, that’s a red flag.
Your WCAG compliance checklist
Here’s a simple checklist you can use right now to assess where you stand:
This guide summarizes publicly available HHS and W3C guidance as of July 2026. It is not legal advice, and the Section 504 rule includes exceptions and limitations not covered in full here. If you need a definitive answer for your practice, talk to a healthcare compliance attorney or an accessibility professional who can review your specific setup.
Sources
- U.S. Department of Health and Human Services. “HHS’ Office for Civil Rights Extends Web and Mobile Accessibility Compliance Deadline.” May 7, 2026. hhs.gov/press-room
- Federal Register. “Extension of Compliance Dates for Nondiscrimination on the Basis of Disability; Accessibility of Web Content and Mobile Applications of Recipients of Departmental Financial Assistance.” May 11, 2026. federalregister.gov
- U.S. Department of Health and Human Services. Section 504 web and mobile accessibility requirements fact sheet. hhs.gov
- W3C. “Web Content Accessibility Guidelines (WCAG) Overview.” w3.org/WAI
- W3C. “Understanding Conformance.” w3.org/WAI
- WebAIM. Contrast Checker. webaim.org
- Section508.gov. VPAT and Accessibility Conformance Report explanation. section508.gov
Ready to make your practice website fully accessible?
We will audit your site against WCAG 2.1 Level AA and give you a prioritized fix list. No jargon, no panic.
Book your free accessibility audit