What a Real Website Accessibility Audit Includes
Business owners who are considering an accessibility audit often don't know what to expect from one. Here's what a real audit covers, how it's different from an automated scan, and what you should receive at the end.
When a service business owner starts looking seriously at website accessibility, they usually hit a wall of conflicting information quickly. One vendor offers an automated scan for free. Another quotes a five-figure enterprise audit. Someone else recommends installing a widget and calling it done.
Understanding what a real audit actually includes cuts through most of that noise. An audit isn’t a scan. It isn’t a certification. And it’s not, in most cases, a project so complex and expensive that a small service business can’t reasonably commission one.
Here’s what the process should look like.
Automated Scanning Is the Starting Point, Not the Audit
Every legitimate accessibility audit begins with automated testing, running the site through tools that flag code-level issues: missing image alt text, form labels that aren’t programmatically associated with their fields, color contrast failures, missing language attributes. These tools are fast, reasonably accurate for the issues they can detect, and freely available.
The problem is what they don’t catch.
Automated tools test what is technically present in the code. They cannot test whether the present code actually works for a person using assistive technology. A form may have field labels in the HTML, but if those labels are structured incorrectly, a screen reader user may still hear nothing useful when they navigate to the form. An automated tool will report the form as passing. A human tester will identify the failure.
The estimate commonly cited in the accessibility field is that automated tools catch somewhere between 30 and 40 percent of WCAG failures. The rest require manual testing.
A real audit combines automated scanning with manual review of the user experience, not just the underlying code.
What Manual Testing Covers
Manual testing evaluates the site from the perspective of users who interact with it in ways that automated tools can’t simulate.
Keyboard navigation. Every interactive element on the site (navigation menus, forms, modal dialogs, carousels, accordions, embedded booking widgets) should be operable using only a keyboard. A tester works through the site without a mouse, checking for elements that trap focus, actions that can’t be triggered via keyboard, and focus indicators that disappear or are too faint to follow.
Screen reader testing. At least one screen reader test (typically NVDA with Chrome on Windows, or VoiceOver with Safari on Mac) evaluates whether a non-sighted user can understand and operate the site. This is where structural issues become apparent: headings that don’t reflect the page structure, links with labels like “click here” that provide no context, images whose alt text describes file names rather than content.
Cognitive and visual review. Does the page structure make sense in a linear read? Are error messages for forms specific and helpful? Do animated elements respect a user’s preference for reduced motion? Is the content written and structured in a way that a user with a cognitive disability can follow?
Mobile accessibility. Touch targets need to be large enough to operate reliably. Content needs to reflow properly when zoomed. A site that passes desktop testing may still have significant mobile accessibility failures.
Third-party components. Most service business websites include embeds, booking tools like Calendly or Acuity, chat widgets, form builders, review widgets, video embeds. Each of these introduces its own accessibility profile that the site owner may not control directly. A thorough audit notes which third-party components have issues and what options exist for addressing them.
What the Deliverable Should Include
An audit report should leave the business owner with three things: a clear inventory of what’s broken, a prioritized order for addressing it, and enough explanation to make intelligent decisions about remediation.
A prioritized issue list. Not an alphabetical dump of every WCAG criterion that was checked. A list organized by severity and impact, which issues create the most significant barriers to users with disabilities, which create the most direct legal exposure, and which are low-priority items that can wait.
Page-specific findings. The report should identify where each issue appears. “Your site has color contrast issues” is not actionable. “Your body text on these four pages fails the 4.5:1 contrast ratio requirement at the specific hex values being used” gives a developer something to fix.
Plain-language descriptions. The business owner commissioning the audit does not need to be a web developer to understand what’s wrong or why it matters. Each finding should describe the issue, who it affects, and what it means in practical terms, without requiring fluency in WCAG criterion numbers to parse.
A remediation roadmap. Not a fixed quote for all the work, priorities shift once the full inventory is known. A clear recommended sequence: fix these first because they affect the most users and create the highest legal exposure, then address these because they’re straightforward, then revisit these when a major site update is planned.
What an Audit Is Not
An audit doesn’t make a website compliant. It produces the information needed to make compliance-directed decisions.
An audit isn’t a one-time event. Websites change, new pages, updated plugins, new third-party embeds, redesigned sections. Accessibility issues introduced after the audit was conducted are not covered by it. For a site that changes frequently, periodic re-testing is part of a real compliance approach.
An audit isn’t a widget. An overlay installed after an audit does not resolve the code-level issues the audit identified. If a business has had an audit done and then installed an overlay as the “fix,” the audit findings are still present in the underlying code. The overlay doesn’t alter what assistive technology actually encounters.
The Value of Starting With the Audit
The audit establishes baseline. For a business that has never evaluated its site for accessibility, the audit answers the question that everything else depends on: what’s actually there?
Most service business owners discover that the situation is more manageable than they feared. Not without real issues, almost every site has them, but not a total rebuild, either. The audit converts an abstract legal and ethical concern into a specific, bounded remediation plan with a realistic cost and timeline. The COREaccess™ Accessibility Leadership System covers the full framework — audit, remediate, train, and monitor — for organizations that need documented, standards-based conformance.
COREaccess™ begins with exactly this kind of audit, a manual and automated review that produces a practical inventory and a prioritized path forward. If you’ve been wondering what’s on your site and what it would take to address it, the ADA overview article provides useful background. A 15-minute conversation is available if you want to talk through the scope of the audit process for your specific site.