Web Accessibility Audit: What I Check and What It Costs
A real accessibility audit is not a free scanner run. It covers both automated and manual testing, and remediation for a small business site typically runs $1,500 to $10,000 depending on what is found. Here is exactly what I check, what it costs, and where people go wrong.
The Short Answer Before We Go Any Further
A real web accessibility audit is not clicking "run" in Lighthouse and calling it done. It combines automated tooling with manual testing by a human who knows what to look for, and the two phases together are what give you an honest picture of where your site stands. For a small business site, remediation after a thorough audit typically runs $1,500 to $10,000, depending on what turns up and how complex your functionality is.
The compliance target that matters legally is WCAG 2.1 Level AA. That is the standard the Department of Justice references, the one courts cite in ADA web accessibility lawsuits, and the one I use as the benchmark for every audit I run. This article covers what I actually check, the five issues I find on nearly every site, honest cost ranges for fixing them, and the failure modes I see most often when remediation goes sideways.
What the Legal Risk Actually Looks Like
If you think ADA web accessibility lawsuits are something only Fortune 500 companies deal with, the data says otherwise. More than 4,000 federal ADA web accessibility lawsuits were filed in 2023 alone, according to UsableNet's 2023 ADA Digital Accessibility Lawsuit Report. The majority of those suits targeted small and mid-sized businesses, and financial services consistently ranks among the top five most-sued industries. A local mortgage broker or independent insurance agency is not flying under the radar here.
The legal foundation matters too. In March 2022, the Department of Justice issued formal guidance confirming that websites are places of public accommodation under Title III of the ADA. That settled what had been a genuinely contested question. If your business serves the public online, your website is subject to accessibility requirements, full stop.
The business case goes beyond legal risk. About 26 percent of U.S. adults live with some form of disability. Those are potential customers who may be running into accessibility barriers that silently filter out potential customers on your site right now, without you knowing it. Average lawsuit settlements vary widely and I will not cite a precise number because they genuinely do, but remediation before a complaint is nearly always cheaper than responding to one after the fact.
What I Actually Check During an Audit
I run every audit in two phases, and neither phase is optional.
Phase One: Automated Tooling
I start with Axe, WAVE, and Lighthouse, plus browser-based extensions that surface issues in context. Automated tools are fast, consistent, and good at catching certain categories of failures reliably: missing form labels, images without alt attributes, low color contrast ratios, and some heading structure problems. The caveat is significant: automated tools detect roughly 30 to 40 percent of WCAG failures at most. The WebAIM Million 2024 study found that 96.3 percent of home pages had detectable WCAG 2 failures, with an average of 56.8 distinct errors per page. Automated tools could catch some of those. The rest require a human.
Phase Two: Manual Testing
This is where the real audit happens. I test keyboard navigation through every interactive element on the page: links, buttons, forms, modals, carousels, dropdown menus. I test with NVDA on Windows and VoiceOver on macOS and iOS. I verify that form labels are programmatically associated with their inputs, not just visually adjacent. I review focus order to confirm it follows a logical reading sequence. I do color contrast spot-checks beyond what automation catches, particularly on UI components and interactive states. If the site has PDFs or downloadable documents, those get reviewed separately.
The deliverable is a written report organized by severity: critical, serious, and moderate. Each issue includes the WCAG criterion it violates, the affected URL, a plain-language description of what is broken, and specific guidance on the fix. This is also why I include accessibility checks I run before any site goes live, so issues get caught before they reach production.
The Five Issues I Find on Almost Every Site
These are not edge cases. They show up constantly, and they are the same issues that appear most often in accessibility complaints.
1. Missing or Non-Descriptive Alt Text (WCAG 1.1.1)
The WebAIM Million study found missing alt text on 54.5 percent of home pages tested. WCAG 1.1.1 requires that all non-decorative images have a text alternative that conveys the same information. "Image" or "photo" does not qualify. Neither does leaving the field blank on a functional image. Fixing this means reviewing every image on every page and writing meaningful alternatives, or programmatically marking decorative images with alt="" so screen readers skip them correctly. Difficulty: low to moderate, depending on how many images the site has and whether the CMS supports alt text fields properly.
2. Insufficient Color Contrast (WCAG 1.4.3)
Low color contrast was the single most common failure in the WebAIM Million study, found on 81 percent of home pages. WCAG 1.4.3 requires a minimum 4.5:1 contrast ratio for normal text and 3:1 for large text. A lot of sites use light gray body text on white backgrounds because it looks clean in design mockups. It is nearly illegible for users with low vision. Fixing this requires updating CSS, which sounds simple but often touches brand colors that require a design conversation. Difficulty: low technically, moderate organizationally.
3. Form Fields Without Programmatic Labels (WCAG 1.3.1 and 4.1.2)
WebAIM found missing form input labels on 48.6 percent of home pages. Placeholder text is not a label. A visually adjacent text element that is not programmatically associated via a for attribute or aria-labelledby is not a label either. Screen readers announce unlabeled fields as "edit text" or nothing at all. This blocks users from completing forms entirely. Fixing it requires proper HTML label associations or ARIA attributes added to every input. Difficulty: low to moderate.
4. Missing Skip Navigation Links (WCAG 2.4.1)
Skip navigation links let keyboard users bypass the main navigation and jump directly to the page content. Without them, someone navigating by keyboard has to tab through every nav link on every page before reaching the content they came for. WCAG 2.4.1 requires a mechanism to skip blocks of repeated content. Adding a skip link is a small HTML and CSS change, often a two-hour fix. It is also consistently absent on sites I audit. Difficulty: low.
5. Inaccessible PDF Documents (Multiple Criteria)
PDFs are their own accessibility problem. A scanned PDF is an image with no text layer. A generated PDF without document tags provides no reading order information to assistive technology. Remediating a PDF properly requires tagging, reading order verification, and alt text for any images within the document. If a business has dozens of PDFs, this category alone can be the most time-consuming part of remediation. Difficulty: moderate to high.
WCAG Levels Explained Without the Jargon
WCAG is organized into three conformance levels. Level A covers the most fundamental accessibility barriers, things so basic that without them, some users simply cannot use the site at all. Level AA is the legal and industry standard target, the one referenced in DOJ guidance and the overwhelming majority of ADA web lawsuits. Level AAA is aspirational. It requires things like sign language video interpretation for all audio content. It is not something small businesses are expected to achieve, and it should not be confused with what compliance actually requires.
I treat accessibility is a baseline of professional work, not a premium feature. That philosophy shapes how I audit: AA is the floor, not an optional upgrade tier.
On WCAG 2.1 versus 2.2: WCAG 2.2 was published in 2023 and added new criteria, most notably around focus appearance and dragging motions. It is worth knowing about, and I note 2.2 issues when I find them. But most legal actions still reference WCAG 2.1 Level AA as the standard. If you are a small business serving the public online, aim for WCAG 2.1 Level AA. That is the clear decision rule.
What Remediation Actually Costs, and Why Overlays Do Not Count
Here are honest cost ranges based on what I actually see:
- Small site, 10 to 20 pages, minor issues: $1,500 to $3,500
- Medium site, 20 to 50 pages, moderate issues: $3,500 to $7,000
- Sites with custom functionality, complex forms, interactive components, or a large PDF library: $10,000 and up
These are remediation costs after audit. The audit itself is a separate line item, typically $500 to $2,000 depending on site size and the depth of testing required. For context on how accessibility remediation fits into overall project costs, the retrofit premium is real. The Web Accessibility Initiative's research suggests fixing accessibility after the fact costs 10 to 30 times more than building it in from the start. That is not a scare tactic; it is a direct consequence of having to reverse-engineer markup and layout decisions that were made without accessibility in mind.
On Overlay Widgets
I will say this plainly: overlay products like AccessiBe and AudioEye do not achieve WCAG compliance. They layer JavaScript over an inaccessible site and add a toolbar that users can theoretically adjust. They do not fix the underlying code. Screen reader users in particular have documented that overlays actively interfere with their assistive technology, introducing new barriers rather than removing existing ones. The National Federation of the Blind and the broader accessibility professional community have formally opposed these products. There is also a legal exposure argument: commissioning an overlay creates a record that you knew about accessibility concerns and chose a non-compliant solution. That is not a position I would want to defend in a complaint.
Ongoing Maintenance
A site that passes an audit today can fail tomorrow if a plugin update reintroduces broken markup, a staff member uploads an untagged PDF, or a developer adds a new form without proper labels. Compliance is not a project with a completion date. It is a sustained workflow requirement.
How to Prioritize When Your Budget Is Limited
If you cannot fix everything at once, here is the triage order I recommend:
Priority 1: Form labels and keyboard navigation. These create complete barriers. A user who cannot tab through your checkout process or contact form cannot complete any task on your site. Fix these first, no exceptions.
Priority 2: Color contrast and alt text. High prevalence, frequently cited in complaints, and relatively straightforward to verify and fix. These two categories alone cover the majority of issues found in most lawsuits.
Priority 3: Skip navigation, heading structure, and visible focus indicators. Important for usability and compliance, but they rarely block task completion entirely the way form and keyboard issues do.
Priority 4: PDFs and complex documents. Handle these last unless they are central to your business function. If your users need to download and complete a form to work with you, that PDF moves to Priority 1.
When you hand audit findings off to a developer, a good audit report should include WCAG criterion references, severity ratings, affected URLs, and plain-language fix descriptions. If the developer you hire cannot explain the difference between an aria-label and a visible label, or does not know what WCAG 1.3.1 covers, that is worth probing before work begins. I have written separately about how to scope accessibility requirements before work begins, which covers exactly this handoff.
Quick Prioritization Checklist
- All form inputs have programmatically associated labels
- Site is fully navigable by keyboard alone
- Color contrast meets 4.5:1 for normal text, 3:1 for large text
- All meaningful images have descriptive alt text
- Skip navigation link is present and functional
- Heading hierarchy is logical and not skipped
- Focus indicators are visible on all interactive elements
- PDFs are tagged with proper reading order (prioritize customer-facing documents)
Where This Goes Wrong
The most common mistake I see is treating the audit as the finish line. An audit report sitting in a folder accomplishes nothing. The audit is the starting line.
The second mistake is fixing issues in a staging environment and then deploying changes that overwrite them, or allowing a plugin update to reintroduce broken markup. Version control discipline and a clear deployment review process matter here.
The third mistake is fixing the site technically and then having no accessible content workflow in place. A developer does good remediation work, then a staff member uploads an untagged scanned PDF six weeks later, and the compliance state quietly degrades. The humans who manage content need to understand the requirements too.
The fourth mistake is commissioning a cheap automated-only audit and treating it as a clean bill of health. Automated tools catch 30 to 40 percent of failures. A report that only reflects what Lighthouse found is missing the majority of what a real audit would surface. I have written about questions to ask any developer about their accessibility practice for exactly this reason: vetting matters.
Full WCAG 2.1 Level AA compliance on a content-heavy or dynamically generated site is a sustained process. That is not a reason to avoid it; it is just the honest description of what you are committing to.
A Practical Next Step
If you want a starting point right now, run your site through WAVE (wave.webaim.org) or the free version of Axe DevTools in your browser. That will surface the most obvious automated failures and give you a rough sense of how much is there. If what you find is extensive, or if you want a complete picture that includes manual testing and a prioritized remediation plan, a professional audit is the logical next step.