ADA Compliance Website: Practical Steps for U.S. Owners
ADA Compliance Website: Practical Steps for U. S.
Yes, under U.S. law many websites must be accessible, and the practical benchmark enforcers now use is WCAG 2.1 Level AA, with WCAG 2.2 gaining traction as the newer reference point. The Americans with Disabilities Act reaches state and local government sites under Title II and businesses open to the public under Title III. Neither title lets you off the hook because your site is “just informational” or built on a template.
Here’s what to do this week, before you read another paragraph about legal theory:
- Publish an accessibility statement on your site that names the standard you’re targeting (WCAG 2.1 AA) and how to report barriers.
- Run an automated scan of your ten most visited pages to catch the low-hanging fruit: missing alt text, poor contrast, broken form labels.
- Set up a dedicated accessibility contact (email or phone) that someone actually monitors, not a form that vanishes into a shared inbox.
Compliance Callout: State and local governments face firm deadlines under the DOJ’s 2024 final rule. Entities with 50,000 or more people must comply by April 26, 2026. Smaller public entities get until April 26, 2027, and the smallest jurisdictions have until April 26, 2028. Private businesses under Title III have no fixed statutory deadline, but that has never stopped plaintiffs’ firms from filing.
Key Takeaways
Meeting ADA website accessibility requirements demands WCAG 2.1 AA conformance, layered testing, prioritized remediation, and engineering practices that prevent regressions from creeping back in.
Table of Contents
- Who Has to Comply: Title II Versus Title III
- What Does WCAG Level AA Actually Require?
- Testing Your Site: Automated Tools, Manual Audits, and Real Users
- Building a Remediation Roadmap That Actually Gets Fixed
- Preventing the Next Retrofit: Procurement and Design Practices
- What Belongs in Your Accessibility Statement and Reporting Process
- Enforcement Patterns and How to Lower Your Legal Exposure
- An Engineering Checklist That Keeps Compliance From Sliding Back
- Why the Standard Advice on ADA Compliance Falls Short
- How Bitrupt Turns an Audit Into a Working Site
- Sources
Who Has to Comply: Title II Versus Title III
Think of Title II and Title III as two different insurance policies covering the same risk. Both protect people with disabilities from being shut out of digital services, but they’re triggered differently, enforced differently, and carry different deadlines.
Title II covers state and local government entities: city websites, public school portals, DMV online services, court filing systems. The DOJ’s rule finalized in April 2024 makes WCAG 2.1 Level AA a binding legal requirement for these entities, not a suggestion. Compliance dates scale with population size, with larger jurisdictions facing earlier deadlines. There’s no ambiguity here. If you run a government website, you have a rule with a date attached to it.
Title III covers “public accommodations,” meaning businesses that serve the public: retailers, restaurants, banks, healthcare providers, ed-tech platforms, and marketplaces. Congress never wrote a specific web accessibility standard into Title III. Instead, the Department of Justice enforces it through litigation and settlement agreements, and WCAG 2.1 AA has become the de facto yardstick courts and regulators point to when deciding whether a site provided “effective communication.”
That distinction matters for how you plan:
- Government agencies face a hard deadline and should treat WCAG 2.1 AA as non-negotiable, budgeted, and tracked like any other regulatory obligation.
- Small businesses face litigation risk rather than a rule with a date, but plaintiffs’ firms routinely target restaurants, retailers, and local service businesses with demand letters.
- Nonprofits open to the public generally fall under Title III too, even without a storefront, if they offer services or programs to the public.
- E-commerce operators face outsized exposure because checkout flows, product filters, and account portals are exactly where automated scans and manual testers find the worst violations.
The practical takeaway: don’t wait for a Title II style deadline if you’re a private business. The absence of a fixed date isn’t the absence of risk.
What Does WCAG Level AA Actually Require?
WCAG, the Web Content Accessibility Guidelines maintained by the W3C, organizes accessibility rules into three tiers: A, AA, and AAA. Level A covers the bare minimum. Level AAA is the gold standard that’s genuinely hard to hit across an entire site, even for well-funded teams. Level AA sits in the middle, and it’s the one DOJ has settled on as both achievable and meaningful, which is why it shows up in the federal rule text governing public entities.
AA isn’t an abstract label. It translates into specific, testable requirements that show up again and again in enforcement actions and third-party audits:
- Captions on video content, synchronized and accurate, not auto-generated garbage left uncorrected.
- Alt text on meaningful images, describing function or content rather than repeating a filename.
- Full keyboard navigation, meaning every interactive element, menu, and modal works without a mouse.
- Color contrast ratios of at least 4.5:1 for normal text against its background.
- Accessible forms with programmatically associated labels, clear error messages, and no reliance on color alone to flag a mistake.
Statistic Callout: DOJ’s own guidance flags alt text gaps, poor contrast, missing headings, and keyboard traps as the most common barriers it sees reported. None of these require exotic engineering. They require someone to actually check.
The gap between “we ran a scan and it passed” and “a blind user can complete checkout” is where most companies get burned. Automated tools verify code patterns. They can’t tell you whether a screen reader user can actually finish a purchase.
Testing Your Site: Automated Tools, Manual Audits, and Real Users
Automated scanners are fast, cheap, and catch roughly a third to half of common issues depending on site complexity. They’re excellent at flagging missing alt attributes, insufficient color contrast, and malformed HTML. They’re useless at telling you whether your custom date picker actually works with a screen reader, or whether your “skip to content” link goes anywhere useful.
A reliable testing program layers three methods, each catching what the others miss:
- Automated scanning first. Run tools across your site’s key templates and highest-traffic pages, not just the homepage. This is your triage pass, not your final answer.
- Manual expert audit second. A tester unplugs the mouse and navigates entirely by keyboard, then repeats the walkthrough using a screen reader like JAWS, NVDA, or VoiceOver. This is where complex widgets, custom dropdowns, and multi-step forms reveal their real problems.
- User testing with people who have disabilities third. Recruit actual screen reader users, people with motor impairments, and people with low vision to complete real tasks: check out a product, book an appointment, submit a support ticket. Scenario-based testing surfaces friction that no checklist catches.
Coordinating these three isn’t complicated, but it requires discipline. Run automated scans monthly as a regression check. Schedule manual audits before any major release and quarterly on a rolling basis for existing pages. Book user testing sessions at least twice a year, more often if you’re actively remediating a large site.
Pro Tip: Don’t treat a clean automated report as a finish line. A site can pass every automated check and still be unusable for a screen reader user if a modal traps keyboard focus or a custom widget has no accessible name. Automated tools are a floor, not a ceiling.
Once you’ve run all three, consolidate every finding into one prioritized ticket list, tagged by severity and page, rather than three separate reports that nobody cross-references. That single list becomes your remediation roadmap.
Building a Remediation Roadmap That Actually Gets Fixed
An audit report full of unranked findings is where good intentions go to die. You need triage categories, timelines, and named owners, or the list sits in a shared drive until someone gets sued.
Sort every finding into one of four buckets:
- Critical: blocks access entirely, such as a checkout flow that can’t be completed by keyboard or a login form with no accessible labels.
- High: significantly degrades the experience, like missing captions on instructional video or contrast failures on primary navigation.
- Medium: creates friction but has a workaround, such as a secondary icon missing alt text.
- Low: minor polish items, like inconsistent heading structure on a rarely visited page.
Timelines should scale with your site’s size and your engineering capacity. A useful rule of thumb:
- Small sites (under 50 pages): Fix all critical and high items within 30 days, medium items within 90 days.
- Medium sites (50 to 500 pages, template-driven): Fix critical items within 30 days by patching shared templates and components first, since one fix often resolves dozens of pages at once. High items within 60 to 90 days.
- Large or enterprise platforms: Run a phased remediation across quarters, prioritizing the highest-traffic flows and any page tied to revenue or public services first.
Assign clear roles instead of hoping accessibility becomes “everyone’s job,” which usually means it’s no one’s job:
- A product owner sets priority and owns the remediation calendar.
- A designer fixes contrast, spacing, and interaction patterns at the source, not with patches after launch.
- Engineers implement semantic markup, ARIA where genuinely needed, and keyboard support.
- QA verifies each fix against the original WCAG success criterion, not just “looks fine visually.”
- Legal counsel reviews your public accessibility statement and any settlement obligations if litigation is already underway.
- Third-party vendors supplying widgets, chat tools, or booking systems need their own acceptance criteria, since a single inaccessible embedded tool can undo months of remediation work elsewhere.
Verification isn’t optional. Every “fixed” ticket should be retested with the same method that caught it: if a screen reader audit found the problem, a screen reader retest closes it, not a visual glance from the person who wrote the code.
Preventing the Next Retrofit: Procurement and Design Practices
Retrofitting accessibility into a live product costs far more than building it in from the start, largely because you’re now untangling components that were never designed for keyboard focus order or screen reader announcements. Embedding accessibility requirements into procurement and design is the single most effective lever for controlling long-term cost, and it’s the one most organizations skip until after their first complaint.
Start with contract language. Any RFP or vendor agreement for a website, app, or SaaS tool should require:
- WCAG 2.1 AA conformance as a defined deliverable, not a vague “accessibility best efforts” clause.
- A VPAT (Voluntary Product Accessibility Template) from the vendor, documenting exactly which success criteria the product meets.
- A remediation SLA specifying how quickly the vendor must fix any accessibility defect discovered after delivery.
On the design and engineering side, a handful of front-loaded habits prevent most of the expensive problems:
- Use semantic HTML first. A native
<button>handles keyboard focus and screen reader announcements automatically. A<div>styled to look like a button doesn’t, and every workaround adds fragile code. - Limit ARIA to where it’s genuinely needed. Overused ARIA attributes often break more than they fix.
- Design keyboard-first interaction patterns, especially for modals, dropdowns, and multi-step forms, rather than bolting on keyboard support after a mouse-only design ships.
- Build on accessible component libraries so fixes propagate across the entire site instead of being reapplied page by page.
Set recurring accessibility checkpoints at each major design and development milestone, not just before launch. Catching a contrast problem in a Figma file costs a few minutes. Catching it in production costs a sprint.
What Belongs in Your Accessibility Statement and Reporting Process
Your accessibility statement is a public commitment, and the DOJ’s guidance treats it as part of demonstrating good-faith effort while remediation is underway. It should never be a single vague sentence buried in your footer.
A statement worth publishing includes:
- The specific standard you’re targeting, generally WCAG 2.1 Level AA, so visitors and auditors know what you’re measuring yourself against.
- Known limitations, stated honestly: if a legacy PDF library isn’t yet accessible, say so and give a fix date if you have one.
- A working contact method for reporting barriers, ideally both email and phone, since not every user prefers the same channel.
- The date the statement was last reviewed, so it doesn’t read as a stale placeholder from three years ago.
Live Caption AI’s guidance on writing accessibility statements offers useful phrasing examples if you’re drafting one from scratch, and a real-world reference like WeFinanceU’s published accessibility statement shows how a concise, specific version reads in practice.
Set a response SLA for your reporting channel, something like acknowledging every report within two business days and providing a remediation timeline within ten. Track every report in the same system as your audit findings, because a user complaint is often the fastest way to surface a bug your automated scanner missed entirely.
While fixes are in progress, offer real interim alternatives: a staffed phone line for completing a transaction, an offer of assisted form completion, or accessible document formats on request.
Pro Tip: Never let an interim alternative become a permanent excuse. A phone line is a bridge to compliance, not a substitute for it. DOJ has made clear that alternatives support access while you fix the underlying problem, not instead of fixing it.
Enforcement Patterns and How to Lower Your Legal Exposure
DOJ’s enforcement playbook looks different depending on which title applies to you. For Title II entities, the agency now has a binding rule with specific compliance dates, which means enforcement will increasingly follow a checklist rather than a lawsuit. For Title III businesses, DOJ still relies primarily on guidance and case-by-case settlement agreements, and private plaintiffs’ firms fill the gap with demand letters and lawsuits.
Statistic Callout: DOJ’s own guidance identifies the same handful of barriers triggering most complaints: missing alt text, poor color contrast, inaccessible forms, and keyboard traps in navigation menus and modals. These aren’t obscure edge cases. They’re the first things a competent audit finds.
Common triggers for a complaint or demand letter include:
- A checkout or account creation flow that can’t be completed by keyboard alone.
- Video content with no captions, especially on marketing or training pages.
- Contact and support forms with unlabeled fields that screen readers can’t parse.
- A PDF-heavy document library with no accessible alternatives.
Practical steps that meaningfully reduce exposure:
- Document your remediation plan in writing, with dates, owners, and progress notes, so you can show good-faith effort if a complaint arrives.
- Commission a third-party audit rather than relying solely on internal automated scans; an outside review carries more weight and catches more.
- Monitor continuously, not just once a year, since new pages and features reintroduce old problems constantly.
- Fix reported issues promptly and confirm the fix with the same person or method that flagged it.
None of this eliminates risk entirely. It does shift you from “we ignored it” to “we have an active, documented program,” which is the difference that matters in a settlement negotiation.
An Engineering Checklist That Keeps Compliance From Sliding Back
Most accessibility programs fail not at the audit stage but months later, when a new feature ships and quietly reintroduces the same keyboard trap someone fixed in March. The fix is treating accessibility like any other quality gate, not a one-time project.
Bake automated accessibility checks directly into your CI pipeline. Running a tool like axe-core on every pull request, and gating merges when critical violations appear, catches regressions before they reach production instead of during the next annual audit. Pair that automated gate with manual smoke tests on major user flows (checkout, account creation, appointment booking) before any release branch ships.
Component libraries matter more than most teams realize. When your buttons, modals, and form fields live in one shared, accessible library, a single fix propagates everywhere at once instead of requiring page-by-page patches across a web platform built on Next.js or React. Semantic HTML underneath those components does most of the heavy lifting for free.
For organizations facing a large backlog with a tight deadline, a remediation pod staffed with senior engineers can close the highest-priority gaps in weeks rather than quarters, since senior engineers make fewer regression-causing mistakes and move through QA cycles faster than a team learning accessibility patterns for the first time.
Pro Tip: Gate your release pipeline on accessibility the same way you gate it on failing unit tests. If a build with a critical accessibility regression can still ship, your CI checks are decorative, not enforced.
Why the Standard Advice on ADA Compliance Falls Short
Most guidance on this topic stops at “run a scan and add alt text,” which treats accessibility like a one-time cleanup instead of an operating discipline. That framing is backwards, and it’s why so many organizations pass an automated audit in January and get a demand letter in October after shipping three new features.
The uncomfortable truth is that compliance drifts by default. Every new component, every third-party widget, every redesigned form is a chance to reintroduce a keyboard trap or a missing label. Treating WCAG 2.1 AA as a release gate, the same way you’d treat a failing test suite, matters more than any single audit.
If you take one thing from this article, prioritize the fix that scales: build accessibility into your CI pipeline and your component library before you worry about polishing every individual page. A single semantic fix in a shared button component solves the problem everywhere that button appears. Chasing page-by-page violations without fixing the underlying pattern just means you’ll be back here next quarter.
— Usama
How Bitrupt Turns an Audit Into a Working Site
Bitrupt runs the remediation work most companies stall on: turning an accessibility audit into shipped, verified fixes without stretching your existing engineering team thin for months.
Where a generalist agency hands you a findings PDF and moves on, Bitrupt’s quality engineering team builds the CI-integrated accessibility checks, component-level fixes, and manual verification into the same sprint cycle as the audit itself, so critical and high-priority issues close in weeks, not the next fiscal year. The typical engagement runs audit, prioritized remediation plan, sprinted fixes with senior engineers, QA verification against the original WCAG criteria, then ongoing monitoring so new features don’t reopen old tickets. For organizations with a backlog and a deadline, Bitrupt also offers staff augmentation: senior engineers who plug directly into your existing team rather than requiring a separate handoff process.
If your site needs a remediation partner rather than another report, start with a conversation about your enterprise software development needs or explore Bitrupt’s full engineering services to see what a scoped audit and sprint plan would look like for your platform.
Sources
- Ada
- Justice Department’s final rule to improve web and mobile app access for people with disabilities (DOJ)
- Federal Register: Accessibility of Web Content and Mobile Apps — DOJ rule
- Section508
