Accessibility Compliance Feels Overwhelming. Here’s Why, and What to Do.

If you’ve started looking into accessibility compliance for your organization and quickly felt overwhelmed, you’re not alone. For most teams, it goes from “we’ll run a scan and clean up some alt text” to “oh no – this is bigger than we thought” faster than they expected.

There’s a real reason for that: the technical standard is dense, the legal landscape keeps tightening, and the gap between “passes an automated check” and “meets accessibility compliance standards” is much wider than most teams realize at the start. Here’s what this work actually involves, and where it tends to catch teams off guard.

The limits of automated testing

Most accessibility programs start with an automated scan, and for good reason. These tools are fast, affordable, and they catch a meaningful set of issues.

While useful, the vendors who build these tools generally say automation only catches about 30 to 40 percent of the issues on a typical web page. A clean scan doesn’t actually mean a compliant site: it means the site cleared the bar your tooling could measure, which is a small slice of the actual standard. The rest of the issues require human review.

Why can’t the tools catch all the accessibility issues? The answer comes down to context. Accessibility isn’t really about code, it’s about whether real people can use what’s been built. A scanner can confirm an image has alt text, but not whether that text is meaningful or just a copy-pasted filename. It can verify headings exist, but not whether they describe the content underneath them. It can flag a contrast issue on a button, but not the fact that the button says “Click here,” which gives a screen reader user no context at all.

At a deeper level, automated testing can miss issues that break the experience for entire groups of users. Consider the following examples:

• A form that turns required fields red on submit but never actually announces the error to a screen reader. A blind user could submit the same form three times without understanding what’s wrong. 
• A custom dropdown menu that’s perfectly clickable with a mouse but completely unreachable by keyboard. 
• An order status that’s only communicated through color. A colorblind user can’t tell at a glance whether their order shipped or got canceled. 
• A pop-up dialog or notification that opens visually but doesn’t announce itself or capture keyboard focus, so a screen reader user has no idea it’s there and no way to interact with it. 

These issues, which negatively affect the user experience, are unfortunately not detectable by a scanner and in some cases may result in the app being completely unusable for some users.

The Web Content Accessibility Guidelines (WCAG), a standard most accessibility programs measure against, reflects all of that complexity. The AA level alone includes around 50 success criteria, each with its own techniques, exceptions, and edge cases. Real expertise takes years to develop. A small number of specialists have put in that time, but most teams doing accessibility work today are learning on the job – and that’s the norm, not the exception.

Documents are part of the picture too

The website itself is only one piece of the picture. Every PDF, Word document, and downloadable form your organization publishes counts as part of your digital presence. The same accessibility expectations apply to these too.

That catalog usually goes deeper than people realize: product documentation, contracts, policy documents, tax and benefits forms, annual reports, application forms, marketing collateral. Each of these needs proper tagging, logical reading order, alternative text for visuals, accessible tables, and a number of other things that don’t carry over from a standard “Export to PDF.”

Document remediation alone can take a mid-sized organization months of focused work, and it’s the area where automated tools help the least. It’s also the piece teams most often miss when they first scope the project.

What the public-sector rollout has shown

If all of this is starting to sound like a lot, you really aren’t alone. Even well-resourced public entities are finding this work much harder than expected, and the recent rollout of the ADA’s Title II web accessibility rule is a good example of why.

In April 2024, the Department of Justice (DOJ) finalized a rule requiring state and local governments – cities, counties, school districts, transit agencies, public libraries – to bring their websites and apps up to WCAG 2.1 Level AA. These organizations had clear deadlines, a defined technical target, and in many cases dedicated staff and earmarked budget – essentially every advantage you’d want when starting a project like this.

Even with all of that, the timeline turned out to be difficult. As entities started auditing their sites, apps, and document libraries, the actual scope was larger than expected. The DOJ has since extended the compliance deadline by a full year. This is a clear acknowledgment that this work is harder in practice than it looks on paper.

What this means for private businesses

These obligations don’t stop at the public sector line. Title III of the ADA covers “places of public accommodation”, a category that courts have increasingly ruled includes private business websites. That includes retailers, restaurants, banks, hotels, healthcare providers, e-commerce sites, SaaS platforms, and most other digital services that customers interact with.

Lawsuits against private businesses for inaccessible websites have climbed steadily in recent years. Some plaintiffs’ firms now specialize in identifying inaccessible sites and filing complaints at scale. Settlements are rarely cheap, and the cleanup work that follows usually costs more than building things accessibly from the start would have. Given how much even well-resourced public entities are struggling with this work, private businesses without dedicated accessibility teams are often further behind than they realize.

That said, legal exposure isn’t the most useful way to frame this work. About one in four U.S. adults lives with some form of disability. A site that’s hard for them to use isn’t just a legal risk – it’s a real loss of customers, employees, and applicants. Accessible design also tends to be better design overall: clearer language, more thoughtful navigation, captions that help in noisy or quiet environments alike, and content structures that search engines understand better.

Done seriously, accessibility is one of those rare investments that improves your legal standing, your user experience, your brand, and your bottom line all at once.

You don’t have to figure this out alone

The honest summary is this: accessibility is hard to get right, and the people who do it best have spent years building that expertise. If your team is feeling like this is a lot, that’s a fair response – the work really is bigger than it looks at first.

The first step usually isn’t a remediation project. It’s a diagnostic: an honest read on where things actually stand, where the real gaps are, how serious they are, and what a realistic path forward looks like for your specific team. That alone tends to take a lot of the pressure off as a clear picture and real plan is uncovered. 

From there, a complete accessibility program pulls together a few layers: automated testing, manual expert review for the things automated tools can’t catch, assistive technology testing with screen readers and keyboards, document remediation across your existing library, and a governance process to maintain accessibility for the long term. That’s a lot to coordinate internally, which is why most organizations doing this seriously bring in a partner.

If you’re staring at a Title II deadline, an unclear sense of your exposure, or just a growing feeling that what you’re doing isn’t quite enough, that’s exactly where we come in. Zirous can help you get a clear, honest read on where you actually stand and what a path towards full accessibility looks like for your organization.