How to Audit Your Local Government Website for Accessibility

To audit your government website for accessibility, define which pages, documents, and tools are in scope, run automated scans, test manually with a keyboard and screen reader against WCAG 2.1 AA, review PDFs and third-party tools, and record every issue in a prioritized fix log. Repeat the audit on a regular schedule.

If you work for a city, county, town, or special district with a small communications or IT team, the word “audit” can sound like a project that needs a consultant and a big budget. It doesn’t have to. The ADA Title II rule uses WCAG 2.1 AA as its standard. After DOJ extended the dates by a year, governments serving 50,000 or more residents have until April 26, 2027, and smaller governments and all special districts have until April 26, 2028. The extension left the WCAG 2.1 AA standard and the scope of covered content unchanged, so starting now lets you spread the work out instead of facing it all at once.

Here is the accessibility audit checklist at a glance: define your scope, run scans, test by hand, review documents and third-party tools, build a fix log, and publish an accessibility statement.

What Does a Website Accessibility Audit Cover?

A website accessibility audit is an evaluation of your pages, documents, forms, media, and third-party tools against WCAG 2.1 AA. It combines automated scans, manual testing, and checks with assistive technology.

It helps to separate three things that often get blurred together. A scan is a quick automated check that flags certain technical problems. An audit adds a person who tests how the site works and records what they find against a standard. Testing with people who use assistive technology every day goes a step further and shows how real tasks go for them. A small team can start with the first two and add the third when the budget allows.

WCAG organizes its requirements around four principles: content must be perceivable, operable, understandable, and robust. Keep them in mind as a simple way to sort what you find.

Step 1: How Do You Define Scope and Prioritize?

Start by writing down what is in scope. For most local governments that includes the home page, city council agendas and minutes, utility billing or payment pages, permit and license forms, contact information, emergency alerts, PDFs, embedded tools, recorded meetings, and any mobile app.

If you can’t cover everything at once, sample. Use your website analytics to rank pages by how many residents visit them, then begin with the pages tied to everyday needs, such as paying a bill, applying for a permit, finding a meeting, or reading an alert. A broken payment page matters more than an old news item. Keep the scope list so your next audit has something to compare against.

Step 2: What Can Automated Scans Tell You?

Free and low-cost scanners are a good first pass. They catch issues such as missing alt text, low color contrast, and form fields without labels, and they can check many pages quickly.

Scans find only a portion of accessibility problems. They cannot tell you whether alt text is meaningful, whether the reading order makes sense, or whether someone using a keyboard can finish a task. Treat the results as a starting list of items to confirm, not a pass or fail grade for the whole site.

Step 3: How Do You Test Manually?

Manual testing is where an audit earns its name, and much of it needs only your keyboard and a little patience.

Set the mouse aside and move through each priority page with the Tab key. Check that the order makes sense, that you can always see where focus is, and that you never get stuck. Then turn on the screen reader built into your computer or phone and listen to the page. Headings, links, images, and form fields should each make sense when read aloud.

Zoom the page to 200 percent and then 400 percent to confirm that text resizes and the layout reflows without hiding content. Check color contrast, and make sure color is never the only way to understand something, such as a red error with no text. Confirm that form fields have labels and that error messages explain what to fix. Look for captions on video and transcripts for audio.

Finally, test whole journeys instead of single pages. Try finding the next city council agenda, or paying a utility bill from start to finish. That is how residents experience your site.

Step 4: What About Documents, Video, and Third-Party Tools?

Your website is more than its pages. Review the PDFs you post, especially agendas, minutes, forms, and notices. Check that recorded council and board meetings have captions.

Then look at the tools your vendors provide, such as payment portals, calendars, maps, and online forms. Content provided through contractors and vendors is covered by the Title II rule, so your government stays responsible for it. Ask each vendor for conformance documentation, often called an accessibility conformance report, and test a few key tasks yourself to confirm it holds up.

Step 5: How Do You Build a Fix Log?

A fix log turns findings into action. A simple spreadsheet works. Give each issue its own row with the page or URL, a description of the problem, the WCAG criterion, a severity, an owner, a target date, and a status.

Sample row:
Page: City council agendas page
Issue: Agendas are posted as scanned images with no readable text
WCAG criterion: 1.1.1 Non-text Content
Severity: High
Owner: City clerk
Target date: [Date]
Status: Not started

Rank severity by whether the issue stops a resident from completing a task. A form that cannot be submitted with a keyboard is high priority, while a decorative image with a missing description can wait. Give every row an owner and a date so the list does not turn into a wish list.

Step 6: Why Publish an Accessibility Statement and a Way to Report Problems?

An accessibility statement tells residents you take this seriously and gives them a way to reach you. Include a clear contact method, such as an email address or phone number, and a commitment for how quickly you will respond.

Treat every report as free testing from the people who matter most. Add each one to your fix log, fix it, and let the person know it has been addressed. That closes the loop with your community and keeps your audit grounded in real use.

How Often Should You Re-Audit?

Audit again after a redesign, whenever you add a new tool or feature, and on a regular schedule such as once a year. New content is the main source of regressions, so a short check each time you post new documents or pages keeps old problems from returning.

Frequently Asked Questions

Can an automated tool audit my website for accessibility?
No. Automated scans find only some issues, so manual testing is required for a real audit.

Should staff or an outside expert run the audit?
Staff can handle scans and basic manual checks. An outside expert helps with a full WCAG 2.1 AA evaluation and screen reader testing, which can be worth it for larger sites or higher-use tools.

Do we have to audit third-party tools like payment portals?
Yes. Content provided through vendors is covered, so request conformance documentation and test key tasks yourself.

How often should we audit?
After major changes and on a regular schedule, such as annually.

Make the Audit a Habit

An accessibility audit is a repeating habit, not a one-time project, and a small team can run it in stages. Each pass gets shorter because you learn where issues tend to appear. The right platform also keeps old problems from coming back. CivAll Sites is built to meet WCAG 2.1 AA out of the box, and CivAll Documents makes the PDFs you post, like agendas, minutes, and forms, readable by every resident without creating a separate copy. See how CivAll supports accessible publishing for local governments.