On April 24, 2026, the DOJ's new ADA Title II web accessibility rule takes effect — requiring WCAG 2.1 AA compliance for state and local government websites. Private businesses aren't directly covered yet, but the standard it sets is about to reshape what "good enough" means for every business site.
The DOJ's ADA Title II rule requires WCAG 2.1 AA compliance for government web content starting April 24, 2026. Private businesses are not directly covered by this deadline, but accessibility lawsuits against commercial sites hit 4,600+ in 2025. Contact forms, booking flows, PDFs, and missing alt text are the most common failures. Here's what changed, what it means for your site, and a 7-point audit you can run this week.
The Department of Justice finalized a rule under ADA Title II that sets a concrete technical standard for web accessibility — for the first time in the law's history. Starting April 24, 2026, state and local government entities with populations of 50,000 or more must make their websites and mobile apps conform to WCAG 2.1 Level AA.
That is not a suggestion. It is a federal regulation with an enforcement date.
WCAG 2.1 AA is the Web Content Accessibility Guidelines standard maintained by the W3C. It covers things like text contrast ratios, keyboard navigation, screen reader compatibility, form labeling, video captions, and how interactive elements behave for people using assistive technology. Until now, the ADA referenced accessibility in broad terms but never pointed to a specific technical benchmark. That just changed.
Smaller government entities (under 50,000 population) have until April 26, 2027. But the direction is unmistakable: the federal government is converting vague accessibility expectations into measurable, enforceable requirements.
The April 24 deadline applies to Title II entities — state and local governments, public universities, transit authorities, courts, and similar public-facing agencies. If your business is a private company, you are not covered by this specific rule.
But here is where it gets relevant.
The DOJ has already taken the position that Title III of the ADA — which covers private businesses — requires accessible websites. They issued formal guidance stating that the ADA applies to the websites of businesses open to the public. They have pursued settlement agreements with private companies over inaccessible sites. And the courts have increasingly agreed.
The Title II rule does not create a new obligation for private businesses. What it does is establish WCAG 2.1 AA as the government's chosen benchmark. When accessibility lawsuits against private companies reach a courtroom, that benchmark is now the obvious measuring stick.
Accessibility lawsuits against private businesses are not theoretical — they are running at industrial scale. According to UsableNet's annual report, federal ADA digital accessibility lawsuits exceeded 4,600 in 2025. That is not a typo. And those numbers only count federal filings — state-level claims and demand letters add thousands more.
The typical targets are not Fortune 500 companies. They are e-commerce shops, restaurants, medical practices, law firms, and service businesses — exactly the kind of businesses that assume the ADA is about wheelchair ramps and parking spaces.
Plaintiffs' attorneys use automated scanning tools to identify sites with accessibility failures, then file complaints in bulk. A single missing form label, an image without alt text, or a booking widget that cannot be operated with a keyboard is enough to trigger a claim.
The average settlement for a first-time ADA web accessibility lawsuit runs $5,000 to $25,000 — plus the cost of remediation and legal fees. Repeat violations go higher. And the plaintiff's attorney fees are typically recoverable, which is why this area of litigation keeps growing.
Most small business websites were never built with accessibility in mind. That does not make them terrible — it means they have predictable gaps that are straightforward to identify and fix.
Low color contrast. Light gray text on a white background looks clean in a design mockup. It fails WCAG contrast requirements and is unreadable for visitors with low vision. The minimum contrast ratio for normal text is 4.5:1.
Missing alt text on images. Every image needs a text description that a screen reader can announce. Decorative images need an empty alt attribute so screen readers skip them. Most small business sites have dozens of images with no alt text at all.
Forms without proper labels. If your contact form has placeholder text inside the input fields but no associated label element, screen readers cannot tell users what information to enter. This is one of the most common failures — and one of the easiest to fix.
Keyboard navigation that dead-ends. Try navigating your site using only the Tab key. If you cannot reach every link, button, and form field — or if you get trapped in a widget with no way to Tab out — keyboard-only users are locked out.
PDFs that are just scanned images. A menu, a price list, or a services brochure uploaded as a flat image PDF is invisible to screen readers. Accessible PDFs require tagged content with a reading order.
Auto-playing video or audio. Content that plays automatically without user control is a WCAG failure and a genuine barrier for users with cognitive or sensory disabilities.
These three areas are where small business accessibility breaks down most often — and where the risk is highest.
Contact forms are the front door of most service businesses. If a potential customer using a screen reader cannot fill out your "Request a Quote" form because the fields are not labeled, you have lost that lead and created a legal exposure at the same time.
Booking and scheduling widgets are often third-party embeds. Calendly, Acuity, and similar tools may or may not meet accessibility standards — and their compliance is not your shield. If the widget is embedded on your site, you are responsible for the experience it delivers.
PDFs are the forgotten content. Service menus, intake forms, contracts, and brochures uploaded as PDFs are often completely inaccessible. A scanned document with no text layer is the accessibility equivalent of a locked door with no handle.
These are not edge cases. They are the primary ways your customers interact with your website. And they are exactly what automated scanning tools flag first.
You do not need to be a developer to check for the most critical accessibility issues on your site. Here is where to start:
1. Run a free automated scan. Use WAVE (wave.webaim.org) or Google Lighthouse (built into Chrome DevTools). These tools catch contrast failures, missing alt text, unlabeled forms, and structural issues in seconds.
2. Tab through your entire site. Put your mouse aside and navigate every page using only the Tab key. Can you reach every link, button, and form field? Can you see where focus is at all times? Can you get out of every section?
3. Check every image for alt text. Right-click any image, inspect it, and look for the alt attribute. If it is empty or missing on a meaningful image, that is a failure.
4. Test your forms with a screen reader. Turn on VoiceOver (Mac) or NVDA (Windows, free) and try to complete your contact form. If the screen reader cannot announce what each field is for, your form needs labels.
5. Check your color contrast. Use the WebAIM Contrast Checker. Enter your text color and background color. Normal text needs 4.5:1. Large text needs 3:1. If your brand colors fail, you need alternative pairings for body text.
6. Open every PDF on your site. Select all text with Ctrl+A. If nothing highlights, the PDF is a flat image and needs to be recreated as a tagged, accessible document.
7. Check your embedded widgets. Booking tools, chat widgets, map embeds, and video players all need to be keyboard-operable and screen reader-compatible. If a third-party embed fails, you may need to replace it or add an accessible alternative.
Any issues you find in steps 1 through 3 are the fastest to fix. Steps 4 through 7 may require a developer, but knowing what is broken is half the work.
The April 24 rule is not just about government websites. It is the federal government putting a flag in the ground and saying: this is what accessible means, this is how you measure it, and this is when we start enforcing it.
That signal travels downstream. Vendors who work with government entities will need to meet the standard. Businesses that contract with those vendors will feel pressure to match it. Insurance carriers and legal teams will start asking whether commercial sites meet WCAG 2.1 AA. And plaintiffs' attorneys now have an even cleaner argument in court: the government itself says this is the standard.
Accessibility is following the same path that data privacy took five years ago. First the regulations cover government and large enterprises. Then enforcement patterns and litigation extend the expectations to everyone else. The businesses that build accessibility in now avoid the expensive scramble later.
Accessibility is not a nice-to-have feature you bolt on after a redesign. It is how your site works — or does not work — for a meaningful percentage of your visitors. Nearly one in four American adults lives with a disability. That is not a niche audience. That is your customer base.
The sites we build at SitoraWeb are structured for accessibility from the start: semantic HTML, proper heading hierarchy, labeled forms, sufficient contrast, keyboard-navigable interfaces, and alt text that actually describes what is in the image. Not because a lawsuit might happen — because that is what a well-built site looks like.
If your current site has never had an accessibility review, this is a good month to start. The deadline is real, the legal trend is clear, and the fixes are almost always simpler than business owners expect.
👉 Get an accessibility review or Book a strategy call with Sitora
If this article reflects the kind of problem you are solving, these are the most relevant next steps inside SitoraWeb.
Improve trust, search visibility, and lead quality with a custom website built around how buyers actually compare options.
Explore Website ServicesBuild secure portals, dashboards, internal tools, and customer-facing web apps that remove operational friction.
Explore Web App ServicesGet validation, workflow analysis, and a roadmap before you commit to the wrong build path.
Explore ConsultingThe rest of the blog covers search strategy, site architecture, analytics, automation, and common mistakes that slow down growth.