An ADA Title II web rule checklist for small towns

The checklist at a glance

The checklist below is the Justice Department’s own list of eleven action steps from its First Steps guide, with one line on what each step looks like in a small town office. The steps are suggestions, not requirements. The sections after the table explain each group of steps.

Steps 1 and 2: the rule and your date

Steps 1 and 2 are about knowing what is asked and by when. The rule asks that web content and mobile apps meet WCAG 2.1 Level AA. Towns and counties under 50,000 people, and every special district, have until April 26, 2028. Governments of 50,000 or more have until April 26, 2027.

Your population for this purpose is the count in the most recent decennial Census, which today means 2020. A department takes the population of its parent government, so a town’s police department shares the town’s date. Our plain guide to the rule covers step 1, and the deadline tracker follows the dates, the pending lawsuit and what the Department has said about future changes.

• We have read a plain summary of the rule.
• We know our population in the 2020 Census and our date.

Steps 3 and 4: people and habits

Steps 3 and 4 are about who does the work and what they need to know. In a small office this is often one or two people. Write down who posts agendas, who updates web pages and who answers a resident who cannot read a file. Then teach the few habits that prevent most problems.

The Department’s guide puts it this way: “It’s important to clearly identify who is responsible for what, so that there is no confusion.” On training it says: “Training your staff is an important step toward ensuring that your public entity complies with the rule.”

For documents, three habits do most of the work: type in Word with real headings and lists, save as a PDF with tags switched on, and post the typed original of a page instead of its scan. Our guide on how to make an agenda PDF accessible walks through each one.

• We have written down who posts what and who answers requests.
• Everyone who posts a file knows the three habits.

Step 5: list what you post

Step 5 is an inventory, and it is the step most small towns skip. List the website’s pages, the documents on it, the forms, and anything a vendor runs for you, such as a payment portal, an agenda system or a mobile app. For most small towns, documents are the largest part of the list.

The Department’s guide explains why the list matters: “Figuring out exactly what web content and mobile apps your public entity currently provides or makes available will help you identify the content and apps that might need to comply with WCAG 2.1 under the rule.”

Count documents by type and by year, not one by one: agendas, packets, minutes, notices, ordinances, budgets, forms, maps. A count like “about 40 packets a year, 120 pages each” is enough to plan with. Our cost calculator turns a count like that into pages.

• We have a list of pages, document types, forms and vendor systems.

Steps 6 and 7: apply the exceptions

Steps 6 and 7 sort your list into what must be fixed and what an exception covers. The rule has five exceptions: archived web content, preexisting documents, content posted by unrelated third parties, individualized password-protected documents, and social media posts made before your date. Each is narrow, and none covers a new agenda posted after your date.

Two exceptions matter most for a town’s documents. Old agendas and minutes posted before your date usually fall under the preexisting documents exception, unless someone still uses them to apply for, gain access to, or take part in a service. Moving files into an archive only helps if all four conditions of the archive exception hold. See the archived content exception and old minutes and PDFs: fix, archive or delete?.

An exception lifts the technical standard only. If a resident asks for an old file in a form they can use, the town still has to help.

• Each item on our list is marked: must fix, exception applies, or remove.

Steps 8 and 9: test, then choose what comes first

Steps 8 and 9 are about finding the problems and choosing an order. Test with an automated tool first, then have a person check what the tool cannot judge. Then fix first what residents use most: the current agenda and packet, the forms people fill in, and the pages that explain how to reach the town.

The Department is direct about the limits of tools: “You won’t be able to use automated testing tools alone, because those tools can’t test for all aspects of accessibility, so you’ll want to use some combination of automated and manual assessments.”

On order, it says: “You might want to think about prioritizing some content to fix right away, while leaving other content to address later.” For documents, our free PDF checker does the automated pass, and the WCAG checklist for documents lists the checks a person makes.

• We have tested our most used pages and our latest packet.
• We have an order for the fixes, starting with what residents use most.

Step 10: ask your vendors

Step 10 is a set of questions for the companies behind your website, your agenda software and your payment or permit portals. Ask each one what its product does for accessibility, what it leaves to you, and for its Accessibility Conformance Report. Get the answers in writing and keep them.

The Department’s guide says: “Your public entity needs to make sure that any content or mobile apps a vendor or contractor provides or posts on its behalf complies with WCAG 2.1 Level AA.” Agenda software is a good example. It often produces a tagged agenda on its own, while the attachments staff upload into a packet stay as they were.

Our vendor letter writes the request for you, and who is responsible: the town or its vendors? explains where the line falls.

• We have asked each vendor in writing and filed the answers.

Step 11: write it down

Step 11 is a short written policy. For a small town, one page is enough: who posts files, how they are made and checked before posting, how a resident asks for help and how fast the town answers, and where the town keeps its record of what it checked and fixed.

The Department’s guide says: “You can help set your state or local government up for success by creating policies on web and mobile app accessibility.” A policy also gives you somewhere to keep dated notes of what was tested, what was fixed and what was asked. Our guide to keeping an accessibility record explains why those dates matter.

Colorado towns have two more items under state rules: a posted accessibility statement and, on one of the accepted paths, a plan updated every year. The statement generator and the Colorado plan template cover both.

• We have a one page policy and a place where dated notes are kept.

What we do about it

What we do about it is steps 8 and 9 for your documents, every month, plus the record from step 11. We find the agendas, packets, minutes and notices your town posted, fix what fails, have a person check every file, and log the result in your dated Readable Record. See how it works or pricing.

This guide explains the rule in plain language. It is not legal advice. For decisions about your town, talk to your attorney.