TL;DR: A web accessibility audit is a structured evaluation of how well a website meets the Web Content Accessibility Guidelines (WCAG), typically WCAG 2.2 Level AA. A complete audit combines automated scanning (which finds roughly a third of issues fast and at scale) with manual testing by trained evaluators using keyboards and screen readers. The deliverable is a report that maps each finding to a specific WCAG success criterion, assigns a severity, and recommends a fix. Audits are point-in-time snapshots — they tell you where you stand today but don’t keep your site compliant as new content is published, which is where continuous monitoring comes in.
If your government agency is preparing for the ADA Title II compliance deadline, one of the first things someone will recommend is a web accessibility audit. The word “audit” gets used loosely — sometimes it means a five-minute automated scan, sometimes a multi-week engagement with a team of testers. Before you commission one, sign a contract, or interpret a vendor’s report, it helps to understand exactly what a web accessibility audit is, what it can and can’t tell you, and how it fits into the larger job of keeping a public website compliant.
This is the conceptual explainer. If you already know what an audit is and want a step-by-step process for running one yourself, see our companion guide on how to conduct a government website accessibility audit. Here, we focus on the “what” and “why.”
What an Accessibility Audit Actually Is
A web accessibility audit is a systematic evaluation of whether a website conforms to a defined accessibility standard. For U.S. government websites, that standard is almost always WCAG 2.2 Level AA — the technical specification referenced by the Department of Justice’s 2024 Title II rule, by Section 508, and by most state procurement requirements.
An audit answers a specific question: Does this site meet each applicable WCAG success criterion, and if not, where does it fail and how badly?
That’s narrower than it sounds. An audit is not a redesign, not a usability study, and not a guarantee. It’s a measurement against a checklist of testable requirements. WCAG 2.2 AA comprises roughly 55 individual success criteria — discrete, mostly testable statements like “text has a contrast ratio of at least 4.5:1” (SC 1.4.3) or “all functionality is operable through a keyboard” (SC 2.1.1). An audit walks through those criteria, page type by page type, and records pass/fail evidence for each.
A good audit is representative, not exhaustive. Nobody hand-tests all 40,000 pages on a county website. Instead, evaluators select a representative sample — the homepage, key landing pages, a search results page, a form, a PDF, a data table, a video page, the login flow — that together exercise every interaction pattern and template on the site. Findings on the sample generalize to the templates that produced them.
The Two Halves: Automated and Manual
Every credible accessibility audit has two components. Skipping either one produces a misleading result.
Automated scanning
Automated tools — like axe, WAVE, Lighthouse, Pa11y, or Govzu — programmatically inspect a page’s HTML, CSS, and computed accessibility tree. They’re excellent at catching machine-detectable failures: missing alt attributes, form inputs without labels, insufficient color contrast, missing page language, duplicate IDs, empty links and buttons, and broken ARIA references.
Automated scanning is fast, cheap, and consistent. You can scan thousands of pages overnight and get the same answer every time. But there’s a hard ceiling on what software can detect. Industry consensus — and the experience of most testing teams — is that automated tools reliably catch only about 30 to 40 percent of WCAG issues. That figure is directional, not a law of nature, but the point stands: a clean automated scan does not mean a site is accessible. We go deeper on this split in automated vs. manual accessibility testing.
Manual testing
The other 60-plus percent requires a human. Manual testing is where a trained evaluator actually uses the site the way a disabled person would, and applies judgment that software can’t:
- Keyboard testing. Can you reach and operate every control using only Tab, Shift+Tab, Enter, Space, and arrow keys? Is the focus order logical? Is there a visible focus indicator? Can you escape a modal? Software can confirm an element is focusable; only a human can confirm the experience makes sense.
- Screen reader testing. Evaluators navigate with NVDA, JAWS, or VoiceOver to confirm that headings, landmarks, link text, image descriptions, and dynamic updates are announced meaningfully. A scanner can verify alt text exists; only a person can judge whether it makes sense in context.
- Cognitive and content review. Is link text descriptive out of context (“Read the 2026 budget” vs. “click here”)? Are error messages clear? Is plain language used? Are instructions understandable?
- Contextual judgment. Does the alt text convey the image’s purpose? Is a decorative image correctly marked empty? Is a heading actually a heading, or just big bold text? These are inherently human determinations.
The manual half is what turns a scan into an audit.
What’s in the Report
The output of an audit is a report (sometimes a spreadsheet, sometimes a formatted document, increasingly a live dashboard). A useful accessibility audit report contains, for each finding:
- The WCAG success criterion it violates — mapped precisely, e.g., “SC 1.4.3 Contrast (Minimum), Level AA.” This matters legally and practically: it ties the finding to the standard your agency is obligated to meet, and it lets you track conformance criterion by criterion.
- The conformance level — A, AA, or AAA. Government sites target A and AA; AAA findings are usually informational.
- A severity or priority rating. Not all failures are equal. A keyboard trap that locks a screen reader user out of a permit application is critical; a slightly-low-contrast footer link is minor. Severity is typically scored by impact on users (does it block a task entirely?), how many users are affected, and how frequently the affected component appears across the site.
- Location and evidence — the page URL, the specific element, often a screenshot or code snippet, and steps to reproduce.
- A recommended remediation — what to change and, ideally, an example of the corrected code or content.
Strong reports also include an executive summary (overall conformance posture, count of issues by severity, the riskiest items) and group findings by template or component so your developers can fix one pattern and resolve it everywhere it appears.
Some audits conclude with a formal conformance statement — for federal procurement, this often takes the shape of a VPAT (Voluntary Product Accessibility Template), which documents conformance criterion by criterion for a product or service.
What Auditors Look For First
Experienced auditors know where the bodies are buried. On government sites, the same failures show up over and over — missing alt text, low contrast, unlabeled forms, inaccessible PDFs, no keyboard access, and missing video captions dominate the findings. Our breakdown of the top accessibility failures on government websites tracks closely with what any audit of a public-sector site will surface. If you want to know what your report will probably say before you commission it, start there.
Who Performs an Audit
There’s a spectrum, and the right choice depends on your budget, risk, and internal capacity.
- In-house staff. A web team can run automated scans and basic keyboard/screen reader checks themselves using free tools. This is appropriate for ongoing hygiene and catching regressions, less so for a defensible compliance baseline. Our audit how-to is written for exactly this audience.
- Specialized accessibility firms. Independent third-party auditors bring trained manual testers, including testers who use assistive technology daily, plus the credibility of an outside opinion. For a formal compliance baseline or when you’re responding to a complaint, a third-party audit carries more weight.
- Disability-led testing organizations. Some agencies engage organizations that employ disabled testers to evaluate real-world usability beyond strict WCAG conformance. This catches issues that pass on paper but still frustrate users.
- Automated platforms. Tools like Govzu handle the automated portion continuously and at scale, and flag the areas that need human follow-up — often used alongside, not instead of, periodic manual audits.
For a high-stakes baseline — say, you’ve received a DOJ complaint or you’re certifying a brand-new site — most agencies use a qualified third party. For staying compliant between baselines, in-house testing plus automated monitoring is the practical norm.
How an Audit Differs From Continuous Monitoring
This is the single most important thing to understand, because it’s the most common and most expensive misunderstanding in public-sector accessibility work.
An audit is a point-in-time snapshot. It tells you the state of your site on the day it was tested. The moment a content editor publishes a new photo without alt text, embeds an uncaptioned video, uploads a scanned PDF, or your CMS pushes a template change, the audit’s findings start to drift out of date.
Government websites are not static. A county site might publish dozens of new pages, agendas, notices, and documents every week, edited by people across departments who have never heard of SC 1.1.1. An audit you paid $20,000 for in January describes a site that no longer exists by March.
Consider the typical lifecycle:
| Audit | Continuous monitoring | |
|---|---|---|
| Timing | Point-in-time | Ongoing, automated |
| Scope | Representative sample, deep | Full site, broad |
| Manual testing | Yes, central | Limited; flags items for human review |
| Catches regressions | No — only re-audits do | Yes — within hours or days |
| Cost model | Per engagement | Subscription |
| Best for | Baseline, certification, complaint response | Staying compliant day to day |
The two are complementary, not competing. The mature pattern is: commission a thorough audit to establish a baseline and remediate, then run continuous monitoring to keep the site from sliding back. Without monitoring, you’re buying a clean bill of health that expires the day after you receive it — and re-auditing from scratch every quarter is neither affordable nor fast enough to catch a problem before a constituent does.
What an Audit Doesn’t Do
To set expectations clearly, an accessibility audit does not:
- Fix anything. It identifies and prioritizes; remediation is separate work. (Plan that work deliberately — an accessibility remediation plan turns a findings list into an ordered roadmap.)
- Guarantee legal protection. Conformance is the goal; a clean audit reduces risk but isn’t a legal shield, and accessibility obligations are ongoing.
- Cover usability beyond WCAG. A site can pass WCAG AA and still be hard to use. Audits measure conformance, not delight.
- Stay current. As above — it’s a snapshot.
How to Read a Report You’ve Been Handed
If a vendor or colleague drops an audit report on your desk, here’s how to make sense of it fast:
- Read the executive summary and the severity counts first. How many critical and serious issues? Those are your near-term legal and ethical exposure.
- Look at how findings map to success criteria. A credible report cites specific SC numbers. Vague findings (“the site has contrast problems”) without a criterion and location are hard to act on. Cross-reference against the WCAG 2.2 AA checklist to confirm coverage.
- Check whether manual testing was done. If the methodology section only mentions automated tools, you have a scan, not an audit — and you’re seeing maybe a third of your real issues.
- Group findings by template. Most “thousands of issues” reports are really a handful of template-level defects repeated across many pages. Fixing the template fixes the count.
- Note the test date and sample. Everything is relative to when and what was tested.
A web accessibility audit is the foundation of a credible compliance program: it tells you, against the actual WCAG standard, where your government website stands today and what to fix first. But “today” is the catch. The day after an audit, your site begins to change, and the report begins to age. That’s why leading agencies pair a thorough baseline audit with ongoing automated monitoring. Govzu continuously scans your government website against WCAG 2.2 AA, maps every finding to its success criterion and severity, and alerts your team the moment a new page introduces a regression — so the clean result you worked for in the audit actually stays clean.