A website accessibility audit is a structured check of your site against a published standard. For state and local governments in the US, that standard is WCAG 2.1 Level AA. This guide is for the person at a school district, city, county or special district who has to commission an audit, or run one in-house, before the ADA Title II deadline.
This guide is general information, not legal advice. Consult your entity's counsel about your obligations.
Why public entities are auditing now
The Department of Justice published its Title II web and mobile app rule on April 24, 2024 (89 FR 31320, codified at 28 CFR Part 35, Subpart H). It adopts WCAG 2.1 Level AA as the technical standard for web content and mobile apps that state and local governments provide or make available.
On April 20, 2026, DOJ published an interim final rule that moved the compliance dates. They are now:
- April 26, 2027 for public entities with a total population of 50,000 or more.
- April 26, 2028 for public entities with a population under 50,000, and for all special district governments.
The extension changed the timing, not the standard. ADA.gov's First Steps guide recommends inventorying your web content and apps, reviewing the rule's exceptions and prioritizing fixes. An audit is how you do the inventory and the prioritizing with evidence. For background on the rule itself, see our guide to what an ADA compliant website means for a public entity.
What an accessibility audit is (and the three kinds)
"Accessibility audit" covers three different things. Know which one you mean before you buy or run one.
Automated scan
Software loads your pages and tests the code against rules: missing alt attributes, form fields with no label, text that fails contrast ratios, empty links and buttons, missing page language. Scans are fast, repeatable across thousands of pages, and good at finding template defects that repeat everywhere.
They cannot judge meaning. A scanner can tell that an image has alt text. It cannot tell that "IMG_4021.jpg" is useless alt text for a bus route map.
Manual expert audit
A trained evaluator works through a sample of pages and tasks with a keyboard, a screen reader, zoom and inspection tools, checking each WCAG success criterion. This is where you learn whether a parent can actually complete the online enrollment form, or whether focus disappears inside the payment widget. The W3C's WCAG-EM evaluation methodology describes how a manual evaluation should be scoped, sampled and reported.
User testing
People with disabilities who use assistive technology every day try real tasks on your site. It is the slowest of the three, but it surfaces problems that pass every checklist and still confuse people.
How much does automation catch?
Less than half of what matters, in most studies, and it depends on how you count.
- The UK Government Digital Service built a deliberately broken page with 143 failures and tested a set of automated tools against it. The best single tool found about 37% to 41% of the barriers, and all the tools combined found 71%. The remaining 29% were missed by every tool (GDS accessibility blog).
- Deque, which makes the axe testing engine, analyzed more than 2,000 of its audits covering about 13,000 pages and nearly 300,000 issues. It found that automated tests identified 57% of issues by volume, compared with the commonly cited 20% to 30% when you count by success criteria (Deque). Note this is a vendor's analysis of its own tool.
The practical reading: automation reliably finds the high-volume, repeated defects, and roughly half or more of the problems still need a human. Section508.gov makes the same point for federal agencies: automated scanners validate only a portion of the standards and are best used for preliminary testing of large sites.
A step-by-step website accessibility audit you can run yourself
A small district or town can do a credible first audit in-house. You will not catch everything a specialist would, but you will find the worst barriers and produce a dated record. The steps below follow the WCAG-EM structure: define scope, explore, sample, evaluate, report.
Step 1: Inventory and scope
List every site and subdomain you run, plus the third-party systems you link to for services. Then pick a representative sample. Include:
- The home page and one page built from each template (news post, department page, calendar, staff directory, search results).
- Key tasks end to end. For a school district: find the enrollment form and submit it, look up the lunch menu, find a board meeting agenda. For a city or county: pay a utility bill or parking ticket, report a pothole, apply for a permit, find council minutes.
- A few pages chosen at random, so the sample is not only your best-maintained content.
- The most-downloaded PDFs and any embedded video.
Write the scope down with the date. "We evaluated 40 pages and 6 tasks on district.org against WCAG 2.1 AA on October 16, 2026" is the first line of your report.
Step 2: Automated scan
Run an automated scanner across the whole site, not just the sample. You can use a browser extension page by page, or a site-wide scanner such as the PillarScan free scan. Group the results by issue type. If the same missing label appears on 900 pages, it is almost certainly one template defect, and that is good news: one fix clears 900 errors.
For context, the WebAIM Million 2026 report detected WCAG failures on 95.9% of the top one million home pages. The most common were low contrast text, missing alt text, missing form labels, empty links, empty buttons and missing document language. Our post on the most common school website accessibility issues walks through each one.
Step 3: Keyboard-only pass
Unplug the mouse. On each sample page and task, use Tab, Shift+Tab, Enter, Space and the arrow keys. Check that:
- Every link, button, menu and form control can be reached and operated.
- You never get stuck inside a widget (a common failure in chat pop-ups and embedded maps).
- The focus order follows the visual order.
- You can always see where focus is. If the outline disappears on the dark header, that is a failure.
- A "skip to main content" link or equivalent lets you bypass the navigation.
Step 4: Screen reader spot checks
Use NVDA (free, Windows) with Firefox or Chrome, or VoiceOver (built in to macOS and iOS) with Safari. Run each key task and listen for:
- Images announced with meaningful descriptions, and decorative images skipped.
- Headings that form a sensible outline when you list them.
- Buttons and links that say what they do ("Pay bill", not "Click here" or just "button").
- Form fields announced with their labels and required status.
- Menus, tabs and accordions that announce whether they are open or closed.
Step 5: Zoom and reflow
Set the browser window to about 1280 pixels wide and zoom to 400%. WCAG 1.4.10 Reflow uses this as its reference point: content should fit a 320 CSS pixel width without scrolling in two directions. Text should not be cut off, overlap or require horizontal scrolling to read. Also zoom to 200% and confirm text resizes without loss of content.
Step 6: Color contrast
Use a contrast checker on body text, links, buttons, placeholder text and text over hero images. Normal text needs a 4.5:1 ratio and large text 3:1. Icons, form field borders and focus indicators need 3:1 against adjacent colors. Also check that color is never the only signal, such as required fields marked only in red.
Step 7: Forms and error messages
Submit each key form empty, then with deliberate mistakes. Errors should be described in text, tied to the field, and announced to a screen reader. Good messages say how to fix the problem ("Enter the date as MM/DD/YYYY"). Every field needs a visible label, not just placeholder text that disappears.
Step 8: Documents and PDFs
Board packets, budgets, forms and newsletters are often the bulk of a public entity's content. Open the most-used PDFs and check for real text (not scanned images), tags, a logical reading order, a document title and language, and alt text on charts. The rule includes limited exceptions for some archived content and preexisting documents; review them with counsel rather than assuming a file is exempt.
Step 9: Third-party portals
Payment processors, student information systems, permit portals, agenda management tools and job applications often live on a vendor's domain. Under the Title II rule, content that you provide through contractual, licensing or other arrangements is still your responsibility. Run the same keyboard and screen reader checks on those tasks and record which vendor owns each issue.
Step 10: Video and audio
Prerecorded video needs accurate captions (auto-generated captions usually need editing). Prerecorded video where important information is only visual needs audio description. Live streams of board and council meetings need live captions. Audio-only content such as podcasts needs a transcript.
Printable WCAG audit checklist
Each check maps to WCAG 2.1 success criteria. All listed criteria are Level A or AA.
| Check | How to test | WCAG 2.1 success criteria |
|---|---|---|
| Images have meaningful text alternatives | Scan, then screen reader | 1.1.1 Non-text Content (A) |
| Video has accurate captions | Watch with captions on | 1.2.2 Captions (Prerecorded) (A); 1.2.4 Captions (Live) (AA) |
| Visual-only video information is described | Watch with eyes closed | 1.2.5 Audio Description (Prerecorded) (AA) |
| Headings, lists and tables are marked up correctly | Screen reader heading list, inspect code | 1.3.1 Info and Relationships (A) |
| Color is not the only way information is shown | Visual review | 1.4.1 Use of Color (A) |
| Text contrast is at least 4.5:1 (3:1 for large text) | Contrast checker | 1.4.3 Contrast (Minimum) (AA) |
| Text resizes to 200% without loss | Browser zoom | 1.4.4 Resize Text (AA) |
| No two-way scrolling at 400% zoom | 1280px window, 400% zoom | 1.4.10 Reflow (AA) |
| Icons, field borders and focus indicators are 3:1 | Contrast checker | 1.4.11 Non-text Contrast (AA) |
| Everything works by keyboard | Keyboard-only pass | 2.1.1 Keyboard (A) |
| No keyboard traps | Keyboard-only pass | 2.1.2 No Keyboard Trap (A) |
| Skip link or landmarks to bypass navigation | Keyboard, screen reader | 2.4.1 Bypass Blocks (A) |
| Each page has a descriptive title | Check browser tab | 2.4.2 Page Titled (A) |
| Focus order is logical | Keyboard-only pass | 2.4.3 Focus Order (A) |
| Link text makes sense in context | Screen reader links list | 2.4.4 Link Purpose (In Context) (A) |
| Keyboard focus is always visible | Keyboard-only pass | 2.4.7 Focus Visible (AA) |
| Page language is set | Scan | 3.1.1 Language of Page (A) |
| Form errors are identified in text | Submit forms with mistakes | 3.3.1 Error Identification (A) |
| Fields have labels or instructions | Scan, screen reader | 3.3.2 Labels or Instructions (A) |
| Error messages suggest a fix | Submit forms with mistakes | 3.3.3 Error Suggestion (AA) |
| Controls expose name, role and state | Scan, screen reader | 4.1.2 Name, Role, Value (A) |
| Status messages are announced | Screen reader after search or submit | 4.1.3 Status Messages (AA) |
This is a working subset, not the full standard. WCAG 2.1 Level AA has 50 success criteria; a full evaluation covers all of them.
How to prioritize findings
An audit of a typical public website produces hundreds or thousands of findings. Sort them so the first fixes do the most good:
- Anything that blocks a key task. A resident who cannot submit the bill payment form by keyboard, or a parent whose screen reader cannot find the enrollment button, is completely shut out. Fix these first, even if there are only a few.
- Template-level defects. An unlabeled search box in the header or a low-contrast footer appears on every page. One fix in the theme or CMS clears it everywhere.
- High-traffic content. Use your analytics. The home page, calendar and top 20 pages matter more than a 2014 press release.
- Vendor-owned issues. Log them, send them to the vendor in writing with WCAG references, and track responses.
- Everything else, scheduled into routine content work.
How to document the audit
For a public entity, documentation shows the board, residents and, if it comes to it, a federal investigator that you know where you stand and are acting on it. Keep four things:
- A dated audit report. State the scope, standard (WCAG 2.1 AA), sample, tools and assistive technology used, who tested, and each finding with its location and success criterion. Section508.gov's guidance on the essential elements of an accessibility test report is a good template.
- A remediation plan. Each finding gets an owner, priority and target date. Tie dates to your compliance deadline.
- An accessibility statement on your site, saying what standard you are working toward, known issues, and how people can report a barrier or request information in another format.
- Re-test results. Re-check fixed items and record the date. A finding is not closed until someone verifies it.
Be careful with language. An audit records conformance on the date tested, for the pages tested. No scan, score or audit makes a site permanently "compliant" or "certified." Our page on how we score explains what an automated score does and does not tell you.
What to ask an outside auditor or vendor
If you hire an auditor, ask:
- Will you test against WCAG 2.1 Level AA, using manual testing with named assistive technologies, not only automated tools?
- How do you pick the sample? Does it include our key tasks and third-party portals?
- Can we see a sample report with real findings (redacted)?
- Does the price include a re-test after we fix things?
- Will findings include WCAG success criterion numbers, screenshots and code-level fix guidance our web team or CMS vendor can act on?
For software vendors (your CMS, payment portal, SIS or agenda tool), ask for a current Accessibility Conformance Report (ACR), which is a completed VPAT. Read it critically: "Partially Supports" next to 2.1.1 Keyboard is a red flag. Write WCAG 2.1 AA conformance into new contracts and renewals, with a duty to fix reported defects within a set time. Our procurement page covers this in more detail.
What an audit costs
We have not found a reliable published source for typical audit prices, so we will not quote numbers. The main cost drivers are:
- Number of distinct templates and key tasks in scope (not total page count).
- Depth: automated only, manual expert review, or added user testing.
- Volume of PDFs and documents included.
- Third-party systems and mobile apps in scope.
- Whether re-testing and remediation support are included.
How often to audit
Sites change daily, so a one-time audit goes stale within weeks. A workable rhythm:
- Continuous automated monitoring of the whole site, so new template-level and content errors are caught as they appear.
- A manual audit of key tasks at least once a year, and after any redesign, CMS migration or new vendor portal.
- Spot checks by content editors before publishing important pages and documents.
Frequently asked questions
Is an ADA compliance audit the same as a WCAG audit?
For state and local governments, effectively yes. The DOJ Title II rule adopts WCAG 2.1 Level AA as the technical standard, so an ADA website audit for a public entity tests against WCAG 2.1 AA.
Can an automated tool tell us whether we are compliant?
No. Studies from the UK Government Digital Service and Deque show automated tools find somewhere between roughly a third and a little over half of issues. A clean scan is a good sign, not proof of conformance.
When does our entity need to meet WCAG 2.1 AA?
Under the April 2026 interim final rule, public entities with 50,000 or more people must comply by April 26, 2027. Smaller entities and special districts have until April 26, 2028.
Can we run an accessibility audit without hiring a consultant?
Yes, for a first pass. An automated scan plus keyboard, screen reader, zoom, contrast and form checks on your key tasks will surface the most serious barriers. A specialist audit is still worth commissioning for complex portals and before major deadlines.
Are PDFs and third-party portals included?
Generally yes. The rule covers web content you provide directly or through contracts and other arrangements, including documents. Some archived and preexisting content may fall under exceptions, so review those with counsel.
How often should we audit?
Monitor automatically all the time, and do a manual audit of key tasks at least yearly and after any redesign or new vendor system.
Sources
- U.S. Department of Justice, Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities, 89 FR 31320 (April 24, 2024)
- U.S. Department of Justice, Extension of Compliance Dates, interim final rule (April 20, 2026)
- ADA.gov, State and Local Governments: First Steps Toward Complying with the Title II Web and Mobile Application Accessibility Rule
- W3C, Web Content Accessibility Guidelines (WCAG) 2.1
- W3C WAI, WCAG-EM Overview: Website Accessibility Conformance Evaluation Methodology
- GOV.UK Accessibility blog, What we found when we tested tools on the world's least-accessible webpage (2017)
- Deque, Automated Testing Study Identifies 57 Percent of Digital Accessibility Issues (2021)
- WebAIM, The WebAIM Million: 2026 report
- Section508.gov, Essential Elements of an Accessibility Test Report
- Section508.gov, Revised 508 Standards Roadmap