What Government Contractors Need to Know About Web Accessibility

Launching a public-facing website tied to a government health program is just like building any other site, but with much higher stakes for many more stakeholders. When we partnered with Renaissance Benefits to bring Tennessee’s TennCare Medicaid dental program online, we weren’t just creating a digital experience. We were building a lifeline for thousands of families who depend on accessible, affordable care.

That kind of responsibility changes the way you work. Strong design and content still matter, but with government contracts, compliance takes center stage. Section 508, ADA Title II, WCAG, VPAT aren’t just acronyms. They’re the difference between meeting your mission or risking your credibility, your contract and the trust of the people you serve.

Accessibility isn’t optional. It’s literally written into the contract.

Here’s what our TennCare project taught us about navigating the regulations, preparing for audits and building websites that don’t just launch, they last.

Why WCAG Alone Won’t Keep You Compliant

When people hear “accessibility,” their first thought is usually WCAG – the Web Content Accessibility Guidelines. While WCAG is the gold standard for digital accessibility, it’s only one piece of a much bigger compliance puzzle.

If you’re building a website tied to a government-funded program, you’re not just designing for good UX. You’re designing inside a framework of laws and regulations that directly impact whether your site can go live – and whether your organization keeps its contract.

Some rules focus specifically on digital inclusion. Others are broader civil rights and privacy protections that carry digital implications. All of them matter.

Here are the heavy hitters that we had to account for during the TennCare site build – and ones you should have on your radar, too:

• Section 508 of the Rehabilitation Act: Requires government sites (and often state-level sites tied to programs that receive federal funding) to meet accessibility standards or risk disqualification before you even bid.
• ADA Title II: As of 2024, the DOJ now explicitly requires public websites and apps to meet WCAG 2.1 AA standards. No wiggle room.
• Section 1557 of the ACA: Goes beyond accessibility to cover language access and usability for people with limited English proficiency.
• HIPAA & HITECH: If your site collects health data (even through a simple form), you’re suddenly playing by strict privacy and security rules.
• The Plain Writing Act: Yes, even your content must comply. That means clear, plain language, not legalese or jargon.
• State-Level Accessibility Laws: Many states adopt Section 508 standards or create their own. If your contracting with a state agency, assume accessibility is in the fine print.

How a ACR Protects Your Project (and Your Reputation)

When you’re building a government-funded website, accessibility isn’t just a best practice – it’s a deliverable written into the contract. That’s where VPATs and ACRs come in.

So, What Are VPATs and ACRs?

Think of them as your site’s official accessibility “report card.” The Voluntary Product Accessibility Template (VPAT) is the standardized form used to document how well your website or digital product meets accessibility standards such as Section 508 and WCAG 2.1 AA. Once the VPAT is completed, it becomes an Accessibility Conformance Report (ACR) — a formal, shareable record that summarizes the findings in a clear, compliance-ready format.

An ACR doesn’t just say “Yes, we added alt text.” It details exactly how each component of your site does (or doesn’t) meet accessibility requirements.

Why You Shouldn’t Self-Assess

Government agencies require independent verification, and for good reason – it’s difficult to objectively evaluate your own work. For our TennCare project, we partnered with a third-party accessibility service to audit the site. They tested everything – from navigation and color contrast to form behavior and screen reader compatibility. Automated scans caught quick fixes, but the real insight came from manual testing with assistive technologies.

This extra layer of review gave us three big advantages:

1. We met all contractual requirements. No gray areas, no last-minute surprises.
2. We had the paperwork to prove it. The completed ACR wasn’t just nice to have – it was required.
3. Most importantly, the site worked for real people. Families using assistive tech could fully access their TennCare dental benefits.

What We Learned From the VPAT Process

Going through the VPAT audit wasn’t just a box-checking exercise, but a reality check. It forced us to see the website the way regulators, auditors and users with disabilities will experience it. And, it revealed issues about the site that would never show up in a quick scan or checklist review.

Here are the takeaways we wish every team knew before starting:

• Start early. Accessibility can’t be tacked on at the end. Build it into your process from the very first wireframe.
• Bring in experts. Third-party audits not only meet formal requirements, they also help you catch what automated tools miss.
• Documentation matters. When you’re working with a government agency, proving compliance is just as important as achieving it.
• Be ready to iterate. Even with the best planning, audits uncover issues. What matters is how quickly and thoughtfully you address them.

Why Accessibility Matters Regardless of Industry

While our TennCare experience centered on healthcare, these lessons extend far beyond that world. Whether you’re building a site for education, transportation or public services, accessibility compliance is the new standard, not the exception.

If your organization interacts with the public on behalf of a government agency – a Medicaid program, a state university, a transportation department, a local housing authority –-these same accessibility standards apply. Increasingly, accessibility compliance is baked directly into RFPs, vendor contracts and procurement checklists. It’s no longer an afterthought or a “nice-to-have.” It’s a go/no-go factor in securing and keeping public-sector business.

Here’s why this matters, no matter what industry you’re in:

1. You may already be covered. From Section 508 and ADA Title II to state-level policies, many digital experiences tied to public services must legally meet accessibility standards, even if you’re a private-sector partner.
2. Procurement is raising the bar. More RFPs now demand proof: VPATs, WCAG 2.1 AA conformance and demonstrated experience with accessible design. If you don’t have those capabilities – or a partner who does – you’re at a disadvantage before the conversation even starts.
3. Non-compliance is costly. We’re talking contract delays, cancellations, lawsuits, loss of public trust and headlines you don’t want. Accessibility gaps can turn into both legal and reputational risk overnight.
4. Accessible design helps everyone. This isn’t just about meeting regulations. Accessibility makes sites more usable across the board: smoother navigation, better mobile performance, stronger SEO and clearer calls-to-action. The result? A digital experience that works harder for all your users, not just those with disabilities.

Where to Start: Your Accessibility-First Checklist

So, you’ve landed (or are eyeing) a government contract that involves launching a public-facing website. First off: congratulations – that’s a huge win. Second: buckle up, because accessibility and compliance aren’t things you can leave for “later.” They need to be part of your plan from day one.

Here’s how to set yourself – and your project – up for success:

1. Bake Accessibility Into the Brief
   Don’t leave accessibility as a vague line item. Spell it out: Require WCAG 2.1 AA (or 2.2 if you’re forward-thinking), ask vendors to show VPATs or past audit reports, and put accessibility checkpoints directly into your project timeline. If it’s documented early, it’s easier to enforce later.
2. Choose Partners Who’ve Been There
   Not every web team understands the unique demands of government contracts. Look for partners who’ve navigated VPATs, worked with public agencies and can explain compliance in plain English, not legalese.
3. Use the Right Tools – But Don’t Rely on Them Alone
   Automated scanners like WVE or axe DevTools are great for spotting obvious issues, and overlays like AccessiBe can give users extra options. But tools don’t replace intentional design, clear content and manual testing. Think of them as supplements, not shortcuts.
4. Budget for a Third-Party Audit
   If your contract requires a VPAT, you’ll need a qualified auditor to review your site. This isn’t a “nice-to-have” – it’s what ensures you launch on time, with no compliance surprises. Pro tip: Treat accessibility like QA, not a final legal review. Build it into your full dev process.
5. Document Everything
   Government agencies love paper trails. Keep your standards, test logs, fixes and VPATs organized – including updated versions after changes. When someone asks for proof you’ll be ready.
6. Plan for Ongoing Compliance
   Accessibility isn’t one-and-done. As your site grows, so does your responsibility. Run periodic scans, re-test after major updates and train your team. Compliance isn’t just about launch day – it’s about staying accessible every day.