Skip to main content

ADA Title II|WCAG 2.1 AA required by April 26, 2027 (50,000+) and April 26, 2028 (smaller entities, special districts)

Guide

Website Accessibility Audit: A Step-by-Step Guide for Schools, Cities and Counties

How to run or commission a website accessibility audit against WCAG 2.1 AA before the ADA Title II deadline: steps, checklist, priorities, vendor questions.

PillarScan editorialUpdated October 16, 202613 min read

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.

CheckHow to testWCAG 2.1 success criteria
Images have meaningful text alternativesScan, then screen reader1.1.1 Non-text Content (A)
Video has accurate captionsWatch with captions on1.2.2 Captions (Prerecorded) (A); 1.2.4 Captions (Live) (AA)
Visual-only video information is describedWatch with eyes closed1.2.5 Audio Description (Prerecorded) (AA)
Headings, lists and tables are marked up correctlyScreen reader heading list, inspect code1.3.1 Info and Relationships (A)
Color is not the only way information is shownVisual review1.4.1 Use of Color (A)
Text contrast is at least 4.5:1 (3:1 for large text)Contrast checker1.4.3 Contrast (Minimum) (AA)
Text resizes to 200% without lossBrowser zoom1.4.4 Resize Text (AA)
No two-way scrolling at 400% zoom1280px window, 400% zoom1.4.10 Reflow (AA)
Icons, field borders and focus indicators are 3:1Contrast checker1.4.11 Non-text Contrast (AA)
Everything works by keyboardKeyboard-only pass2.1.1 Keyboard (A)
No keyboard trapsKeyboard-only pass2.1.2 No Keyboard Trap (A)
Skip link or landmarks to bypass navigationKeyboard, screen reader2.4.1 Bypass Blocks (A)
Each page has a descriptive titleCheck browser tab2.4.2 Page Titled (A)
Focus order is logicalKeyboard-only pass2.4.3 Focus Order (A)
Link text makes sense in contextScreen reader links list2.4.4 Link Purpose (In Context) (A)
Keyboard focus is always visibleKeyboard-only pass2.4.7 Focus Visible (AA)
Page language is setScan3.1.1 Language of Page (A)
Form errors are identified in textSubmit forms with mistakes3.3.1 Error Identification (A)
Fields have labels or instructionsScan, screen reader3.3.2 Labels or Instructions (A)
Error messages suggest a fixSubmit forms with mistakes3.3.3 Error Suggestion (AA)
Controls expose name, role and stateScan, screen reader4.1.2 Name, Role, Value (A)
Status messages are announcedScreen reader after search or submit4.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:

  1. 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.
  2. 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.
  3. High-traffic content. Use your analytics. The home page, calendar and top 20 pages matter more than a 2014 press release.
  4. Vendor-owned issues. Log them, send them to the vendor in writing with WCAG references, and track responses.
  5. 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

  1. 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)
  2. U.S. Department of Justice, Extension of Compliance Dates, interim final rule (April 20, 2026)
  3. ADA.gov, State and Local Governments: First Steps Toward Complying with the Title II Web and Mobile Application Accessibility Rule
  4. W3C, Web Content Accessibility Guidelines (WCAG) 2.1
  5. W3C WAI, WCAG-EM Overview: Website Accessibility Conformance Evaluation Methodology
  6. GOV.UK Accessibility blog, What we found when we tested tools on the world's least-accessible webpage (2017)
  7. Deque, Automated Testing Study Identifies 57 Percent of Digital Accessibility Issues (2021)
  8. WebAIM, The WebAIM Million: 2026 report
  9. Section508.gov, Essential Elements of an Accessibility Test Report
  10. Section508.gov, Revised 508 Standards Roadmap