Yes, the ADA reaches your website, though how it applies depends on whether you run a public entity or a private business. State and local governments must meet the DOJ’s Title II rule and its WCAG 2.1 Level AA standard on a fixed timeline. Private businesses face no single codified rule yet, but courts and the DOJ treat that same standard as the practical benchmark in litigation. Either way, the fixes are largely the same: contrast, alt text, labeled forms, keyboard navigation, captions, and tagged PDFs. Start with an automated scan, then confirm the results with a manual keyboard and screen-reader check.
TL;DR:
- Private businesses are at risk of litigation relying on WCAG 2.1 AA standards even without a formal web accessibility rule, due to consistent court interpretations.
- Fixes such as contrast adjustments, alt text, form labels, keyboard navigation, and tagged PDFs are essential and should be verified through automated scans and manual testing.
- Conducting phased assessments, starting with quick automated scans and ending with comprehensive user testing, helps manage remediation efforts efficiently over 180 days.
- Accessibility obligations extend to third-party content and vendor-provided widgets, requiring contractual clauses and regular audits to ensure ongoing compliance.
- Improving accessibility also enhances search engine rankings and user experience, making it a valuable asset beyond legal risk mitigation.
Table of Contents
- How the ADA Applies to Government Sites vs. Private Businesses
- What WCAG 2.1 Level AA Actually Requires
- What Are the Most Common Accessibility Barriers on Websites?
- How Do You Assess Whether Your Website Is Accessible?
- How Do You Fix and Maintain Accessibility Over Time?
- What Are the Legal Risks of an Inaccessible Website?
- A 30/90/180-Day Accessibility Action Plan
- What Counts as a “Place of Public Accommodation” Online?
- How Do You Build an Accessibility Policy That Sticks?
- What Accessibility Training Do Content Teams Actually Need?
- When Should You Bring in an Accessibility Consultant?
- What Do Accessibility Audits and Remediation Typically Cost?
- Why Accessibility Is a Marketing Asset, Not Just a Legal Checkbox
- Get Help Auditing and Fixing Your Website’s Accessibility
- Where to Go for Official Guidance and Testing Tools
- Sources
How the ADA Applies to Government Sites vs. Private Businesses
The ADA splits into two tracks, and knowing which one governs your website changes what “compliant” actually means.
Title II covers state and local governments: city halls, public school districts, transit authorities, courts, and public university systems. The DOJ’s 2024 final rule gives Title II entities an explicit technical target for the first time. The rule took effect on June 24, 2024, and requires state and local government web content and mobile apps to conform to WCAG 2.1 Level AA. Compliance dates are phased by population size, with larger public entities facing an early deadline and smaller entities and special districts getting more time. If your organization is a public agency, this is no longer a gray area. You have a named standard and a calendar.
Title III covers “places of public accommodation,” which the DOJ has long interpreted to include businesses open to the public, whether or not they operate a physical storefront. There’s no equivalent codified web rule for Title III yet, and that gap is exactly what creates uncertainty for private companies. Federal courts have split on how directly the ADA reaches websites, particularly around whether a site needs some connection, or “nexus,” to a physical location to fall under the law. Some circuits require that nexus; others have found that a website alone can qualify as a place of public accommodation.
What matters in practice is simpler than the legal theory. Legal analysts note that regardless of which circuit a business sits in, courts and settlement negotiations consistently point to WCAG 2.1 AA as the working benchmark for what “accessible enough” looks like. That consistency is why treating WCAG 2.1 AA as your floor, not your ceiling, is the safer play even without a formal Title III regulation.
Here’s how the two tracks differ in practice:
- Title II (public entities): Bound by a specific rule, a specific standard (WCAG 2.1 AA), and a specific deadline tied to population size.
- Title III (private businesses): No codified rule yet, but consistent judicial and enforcement reliance on the same WCAG 2.1 AA standard.
- Title II obligation scope: Extends to content provided through vendor contracts and licensing, not just internally built pages.
- Title III risk profile: Driven by litigation exposure rather than a fixed compliance date, which means the “deadline” is effectively now.
- Shared practical guidance: ADA.gov’s accessibility guidance frames features like alt text, captions, form labels, and keyboard access as necessary for what it calls “effective communication,” a phrase that shows up in enforcement actions regardless of Title II or Title III status.
The upshot for a private business owner: you’re not waiting on a rule to be finalized before risk exists. Litigation risk exists now, and it moves faster than rulemaking does.
What WCAG 2.1 Level AA Actually Requires
The Web Content Accessibility Guidelines are published by the W3C’s Web Accessibility Initiative and organized into three conformance levels: A (minimum), AA (mid-level, the one that matters legally), and AAA (the strictest, rarely required in full). WCAG 2.1 AA is the version named in the DOJ’s Title II rule and the version courts cite most often in Title III cases, which is why it functions as the de facto legal floor even for businesses with no direct government obligation.
In plain terms, WCAG 2.1 AA translates into a set of concrete, testable requirements:
- Color contrast: Text needs a contrast ratio of at least 4.5:1 against its background for normal text, and 3:1 for large text.
- Text alternatives: Every meaningful image needs alt text that describes its function or content, not just its filename.
- Captions: Pre-recorded video needs captions, and live video needs them too under stricter interpretations.
- Keyboard focus visibility: Anyone tabbing through your site with a keyboard needs a visible indicator showing which element is currently focused.
- Form labeling: Every input field needs a programmatically associated label, not just placeholder text that disappears when the user starts typing.
- Touch target size: Interactive elements on mobile need enough space around them to avoid accidental taps.
WCAG 2.1 AA compliance rate across the web sits far below where it needs to be. The WebAIM Million study found that home pages across a massive sample average dozens of detectable errors each, concentrated overwhelmingly in a handful of categories like contrast and missing alt text.
WCAG 2.2 was published after 2.1 and adds several new success criteria, mostly around focus visibility and target size, without removing anything from 2.1. That means satisfying WCAG 2.2 AA automatically satisfies WCAG 2.1 AA. The practical guidance here: treat 2.1 AA as your legal floor since it’s the version named in current regulation and case law, but aim for 2.2 AA as your working target so you’re not remediating twice when standards catch up.
What Are the Most Common Accessibility Barriers on Websites?
Six issue types account for the overwhelming majority of detectable accessibility failures, and fixing them first delivers the fastest risk reduction for the least engineering effort.
- Low color contrast. Light gray text on white backgrounds is the single most common failure the WebAIM Million tracks. Fix it by running every text and background pairing through a contrast checker and adjusting palette values to hit 4.5:1. A designer usually owns this fix, and it’s verifiable with a five-minute automated scan.
- Missing alt text. Images without alternative text leave screen reader users with no idea what they’re looking at. Content editors should own this one at the CMS level; the verification check is simple: run a scan and look for every “missing alt attribute” flag.
- Unlabeled form fields. A checkout field that only shows a placeholder disappears the moment someone starts typing, and screen readers often can’t announce it at all. Developers need to add programmatic
<label>elements tied to each input, and QA should test every form with a keyboard alone before it ships. - Empty links and buttons. Icon-only buttons with no accessible name (a search icon with no “Search” label, for instance) are invisible to assistive technology. This is a quick developer fix with
aria-labelattributes, verified by tabbing through the page and listening to what a screen reader announces. - Keyboard and focus navigation gaps. If a user can’t reach every interactive element using only the Tab key, or can’t see where focus currently sits, the site fails a core WCAG criterion. Developers own the fix; the verification is manual, unplug your mouse and navigate the entire page by keyboard.
- Untagged PDFs. A PDF without proper heading and reading-order tags is functionally unreadable to a screen reader, even if the visible text looks fine. Content teams need to either tag PDFs properly in Acrobat or replace them with HTML pages where possible.
Pro Tip: Don’t try to fix your entire site at once. Triage by user journey first. Checkout flows, contact forms, and booking widgets carry the highest legal and revenue risk, so remediate those before touching a blog post from three years ago.
How Do You Assess Whether Your Website Is Accessible?
A credible assessment blends three methods, and skipping any one of them leaves real problems undetected. The DOJ’s own guidance for government websites recommends combining automated scanning, manual review, and testing with actual assistive technology users, and that same three-pronged approach applies to any business site.
Automated scanning catches the machine-detectable issues, roughly the six categories above, quickly and at scale. Tools like WAVE, Axe, and Lighthouse can flag contrast failures, missing alt attributes, and unlabeled fields across hundreds of pages in minutes. The limitation is real: automated tools catch an estimated 30 to 40 percent of actual WCAG failures, since they can’t judge whether alt text is accurate, only whether it exists.
Manual checks fill that gap. This means physically navigating your site with only a keyboard (no mouse), and running a screen reader like NVDA (free, Windows) or VoiceOver (built into every Mac and iPhone) through your key pages. You’re listening for whether the reading order makes sense, whether buttons announce their purpose, and whether forms guide the user correctly.
User testing with people who actually use assistive technology day to day is the step most businesses skip, and it’s the one that surfaces problems no scanner or single tester will ever find. Someone who has used a screen reader for a decade navigates completely differently than someone testing it for the first time.
If you bring in a professional auditor, expect a deliverable that ties every finding to a specific WCAG success criterion, ranks issues by severity and user impact, estimates remediation effort, and includes a plan for re-testing after fixes ship. Anything less than that specificity is a checklist, not an audit.
How Do You Fix and Maintain Accessibility Over Time?
Remediation isn’t a one-time project. It’s a workflow, and treating it as a workflow is what keeps a site compliant six months after the audit instead of drifting back into violation the next time a developer pushes a redesign.
The core sequence looks like this: scope the problem by running a full audit, triage findings by user-journey impact and legal exposure, patch the code-level issues (not overlay widgets, more on that below), validate each fix against the original WCAG criterion it addresses, and monitor continuously so new content doesn’t reintroduce old problems. Release gating, requiring an accessibility check before any deploy ships, is what separates teams that stay compliant from teams that pass one audit and slide backward within a year.
Vendor and contract management deserves its own line item. If your booking widget, payment iframe, or chat plugin is inaccessible, your page is inaccessible, full stop, regardless of how clean your own code is. The DOJ’s compliance guidance for Title II entities makes this explicit: obligations extend to content provided through contracts and licensing, not just internally built pages. Build accessibility clauses into every vendor contract, require acceptance testing against WCAG 2.1 AA before signing, and audit third-party widgets on your actual live pages, not just the vendor’s marketing demo.
A few structural habits keep this from becoming a recurring fire drill:
- Schedule automated scans on a recurring basis, not just once after the initial fix.
- Add an accessibility checklist to your release or deployment process.
- Publish an accessibility statement with a public contact channel for reporting issues.
- Keep records of user testing sessions and vendor contract language, since documentation is your best evidence if a demand letter ever arrives.
Pro Tip: If a vendor pitches an accessibility overlay widget as a one-click fix, ask what happens to your legal exposure if a user with a screen reader still can’t complete checkout. Overlays layer a script on top of broken code; they don’t fix the code, and regulators and plaintiffs’ attorneys have both taken notice.
What Are the Legal Risks of an Inaccessible Website?
Litigation, not regulation, is what actually moves most businesses to fix their sites. Digital accessibility lawsuits under Title III have become one of the most active categories of ADA litigation, and the American Bar Association’s analysis notes that most cases settle rather than go to trial, largely because businesses have few strong defenses once a genuine barrier is documented.
That settlement pattern matters strategically. A demand letter alleging inaccessible forms or missing alt text is rarely a bluff worth ignoring, and rarely worth fighting on principle either, since the cost of litigation usually exceeds the cost of remediation.
State law adds another layer plaintiffs’ attorneys actively use. Federal ADA claims typically only produce injunctive relief, an order to fix the problem, but some states permit monetary damages under their own anti-discrimination statutes. That difference is why the same underlying accessibility gap can carry dramatically different financial exposure depending on where the lawsuit gets filed.
Practical mitigation comes down to three habits:
- Keep a documented remediation program. A dated audit, a prioritized fix list, and evidence of progress are your strongest defense if a claim arrives.
- Respond quickly to demand letters. A fast, good-faith remediation commitment often heads off litigation entirely.
- Preserve records of testing and vendor terms. If a third-party widget caused the barrier, your contract language matters when allocating responsibility.
None of this requires perfection. It requires evidence that you took the standard seriously and acted on it.
A 30/90/180-Day Accessibility Action Plan
Momentum matters more than perfection here. A staged plan turns an intimidating audit into a sequence of manageable sprints.
- Days 1 to 30: Run a full automated scan across your site. Fix the glaring, fast issues, contrast failures, missing alt text on key pages, and unlabeled form fields on your most-used forms. Draft an accessibility statement and designate a public contact point for reporting barriers.
- Days 31 to 90: Complete manual keyboard and screen-reader testing on your core user journeys: checkout, contact, and booking flows. Remediate the highest-impact items your scan and manual testing flagged. Update procurement and vendor contract language to require WCAG 2.1 AA conformance going forward.
- Days 91 to 180: Finish a comprehensive, page-by-page audit of the full site. Conduct actual user testing sessions with people who use assistive technology. Put automated monitoring and release gating in place so new content doesn’t quietly reintroduce the problems you just fixed.
| Timeframe | Primary focus | Success signal |
|---|---|---|
| 30 days | Automated scan, quick fixes, public contact point | Contrast and alt text errors resolved on top pages |
| 90 days | Manual testing on core journeys, vendor contracts updated | Checkout/contact/booking flows keyboard-navigable |
| 180 days | Full audit, real user testing, monitoring in place | Recurring scans catch new issues before launch |
What Counts as a “Place of Public Accommodation” Online?
The ADA’s Title III text lists specific categories, hotels, restaurants, retail stores, banks, doctor’s offices, and similar establishments, as places of public accommodation. Courts disagree on how directly that list extends to a website with no physical storefront, but the practical trend across enforcement and settlements leans toward broad coverage.
An e-commerce retailer selling only online, a healthcare provider’s patient portal, a law firm’s intake form, and a bank’s online account management all get treated as extensions of the underlying business’s public-facing operations in most enforcement actions and settlements, even when the business itself has no walk-in location. The safest assumption for any business selling goods, services, or information to the public through a website is that the site itself functions as the storefront, and accessibility obligations follow accordingly.
This matters most for businesses that assume a nexus requirement protects them because they operate exclusively online. Courts remain split on that question, and betting your compliance strategy on a favorable circuit interpretation is a weak position compared to simply meeting WCAG 2.1 AA and removing the question entirely.
How Do You Build an Accessibility Policy That Sticks?
A written policy is what turns accessibility from a one-time audit into an ongoing operational standard, and it’s also your best documentation if a legal claim ever surfaces.
A workable policy names the standard you’re targeting (WCAG 2.1 AA, moving toward 2.2 AA), assigns clear ownership (who signs off before a page ships, who handles reported barriers, who manages vendor conformance), and sets a review cadence, quarterly scans at minimum, with a full manual audit annually. It should also require new content and features to pass an accessibility check before launch, not after a complaint arrives.
Publish an accessibility statement on your site describing your commitment, your target standard, and a public contact method for reporting problems. That statement does double duty: it signals good faith to any regulator or plaintiff’s attorney, and it gives real users a direct channel instead of a lawsuit as their first recourse. The DOJ’s own guidance points to exactly this kind of documented, responsive posture as evidence of a serious compliance effort.
What Accessibility Training Do Content Teams Actually Need?
Most accessibility failures aren’t code problems. They’re habit problems, an editor who forgets alt text, a designer who picks a pretty gray that fails contrast, a developer who ships a form without labels because nobody flagged it in review.
Training should be role-specific rather than a single company-wide seminar everyone forgets within a week. Content editors need a short, recurring refresher on writing meaningful alt text and structuring headings logically. Designers need contrast ratio requirements built into their design system so accessible color choices are the default, not an afterthought caught in QA. Developers need WCAG success criteria baked into their code review checklist, the same way security review works.
The highest-leverage move is building an accessibility check into whatever workflow already exists, rather than adding a separate compliance step everyone ignores under deadline pressure. A CMS that flags missing alt text before publish, or a design system with pre-approved accessible color pairs, changes behavior far more reliably than an annual training session.
When Should You Bring in an Accessibility Consultant?
Bring in outside help when your internal team lacks screen reader expertise, when you’re facing active litigation or a demand letter, or when a full audit needs to happen faster than your internal bandwidth allows.
Selection criteria matter more than most businesses realize. Look for a consultant who tests with actual assistive technology users, not just automated tools with a report generator attached. Ask whether findings get tied to specific WCAG success criteria or delivered as vague summary language. Ask how they handle third-party widgets and vendor-provided content, since that’s where many audits quietly stop short. And be skeptical of anyone whose entire remediation plan is a single overlay script; that approach has repeatedly drawn litigation rather than resolved it.
A strong consultant delivers a prioritized findings report, a remediation roadmap with realistic timelines, and a re-test plan to confirm fixes actually worked once your developers ship them.
What Do Accessibility Audits and Remediation Typically Cost?
Timelines and costs vary widely by site size and how deep the problems run, but a rough shape holds across most businesses. A focused audit on a small to mid-size site typically takes two to four weeks, while a comprehensive audit across a large, content-heavy site can run six to eight weeks or more once manual testing and user sessions are included.
Remediation timelines depend entirely on what the audit finds. Quick wins, contrast, alt text, form labels, can often ship within days once developers have a prioritized list. Deeper structural issues, like an inaccessible checkout flow built on custom JavaScript components, can take weeks of development work and multiple rounds of testing.
Budget planning should separate the audit from the fix. The audit is a fixed, bounded cost. Remediation cost scales with how many custom components your site uses and how much of the work touches core revenue paths like checkout or lead forms, which is exactly why triaging by user journey first, as covered earlier, keeps the highest-value fixes moving before budget runs thin.
Why Accessibility Is a Marketing Asset, Not Just a Legal Checkbox
Accessibility work and marketing performance overlap more than most businesses expect. The same fixes that reduce legal exposure, clean heading structure, descriptive alt text, fast keyboard navigation, also improve how search engines crawl and rank a site. Alt text that actually describes an image gives Google more context, and a logical heading hierarchy is exactly what both screen readers and search algorithms use to understand page structure.
We’ve watched this play out directly. Our work on an SEO improvement following a national relaunch showed how structural cleanup, the kind that accessibility remediation forces you to do anyway, moved rankings in ways a cosmetic redesign never would have. Healthcare clients see this compound further, since healthcare SEO strategies depend heavily on clear, navigable content that both patients and search engines can parse quickly. A partner analysis on accessibility and SEO overlap makes the same case from a different angle: accessible sites tend to convert better because they’re simply easier to use, for everyone, not just users of assistive technology.
None of this replaces legal counsel on your specific exposure. But if you’re already investing in remediation to reduce risk, you’re also investing in UX and discoverability gains that show up in your marketing numbers. That overlap is worth factoring into how you prioritize the work, and how you talk about it internally when the budget conversation comes up.
— Derek
Get Help Auditing and Fixing Your Website’s Accessibility
Some agencies offer a faster path than hiring a standalone accessibility consultant and a separate marketing agency to fix what the audit finds. Because some agencies handle brand development, content, and web performance under one roof, accessibility remediation can be folded directly into your existing site work instead of becoming a second disconnected project competing for the same budget.

Our approach starts with a website audit that can be scoped to include an accessibility assessment alongside the SEO and UX review we already perform. From there, fixes to navigation, forms, and content structure get built into the same brand development process we’d use for any site update, so you’re not paying twice to touch the same pages. If your accessibility work is tied to a larger relaunch or rebrand, our brand story development case work shows how structural and content changes can move together. Reach out to a professional agency to help figure out what to fix first based on where your site currently stands.
Where to Go for Official Guidance and Testing Tools
The DOJ’s Title II fact sheet lays out the exact compliance dates and WCAG 2.1 AA requirement for public entities. The ADA.gov web accessibility guidance page covers what “effective communication” means for both Title II and Title III. For the technical standard itself, the WCAG specification defines every success criterion referenced throughout this guide. The WebAIM Million study shows exactly which errors dominate real-world websites, useful for prioritizing your own fixes. And the DOJ’s small entity compliance guide walks public entities through first steps, including vendor and third-party content responsibilities that apply just as directly to private businesses managing embedded widgets and booking tools.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Sources
- Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments
- Digital Accessibility Under Title III of the ADA
- WebAIM Million