ADA Title II Website Compliance for Public Bodies on WordPress

If you run the website for a town, a county, a water district, a school district, a public library or a community college, you have probably been forwarded the same memo several times this year. The Department of Justice has a new rule for state and local government websites, there is a deadline, and someone in the clerk’s office or the IT department has been asked to sort out ADA Title II website compliance and “make sure we are covered.” Meanwhile the site has fifteen years of council minutes in scanned PDFs, a utility payment portal run by an outside vendor, and a dozen departments that each post their own pages.

This page is for the people holding that memo. It explains, in general terms, what the 2024 rule changed, how our ADA Title II website compliance support works on WordPress sites, and how to plan a large backlog by priority instead of panic. We are a small WordPress team and not attorneys, so treat everything here as technical guidance rather than legal advice. Your city attorney, county counsel or district counsel should interpret the rule for your organization.

The 2024 Title II web rule, in brief

Title II of the Americans with Disabilities Act covers state and local governments and their programs, services and activities. For years, public bodies knew their websites were expected to be accessible but had no federal technical rule to point to. That changed in April 2024, when DOJ published its final Title II web accessibility rule. The technical bar it chose for government web content and mobile apps is WCAG 2.1 Level AA.

In practice, that brings a lot into scope: the main website, department and program pages, online forms, posted documents, video of public meetings, and mobile apps residents use to report potholes or pay bills.

When do you have to meet it? We deliberately leave dates off this page. The compliance dates depend on the population your entity serves and could be adjusted, so a date written here today might be wrong next month. Check the current dates and the full text of the rule, including its exceptions and their conditions, on the official ADA website run by DOJ, and confirm with your counsel how they apply to you.

DOJ had already published web accessibility guidance in March 2022, covering both governments and businesses. Our plain-language summary of DOJ’s earlier web accessibility guidance explains what it said; this page focuses on doing the technical work under the newer rule.

WCAG 2.1 AA as the target, with an eye on 2.2

The rule names WCAG 2.1 AA. The W3C has since published WCAG 2.2, which became a Recommendation in October 2023, adding nine new success criteria and removing 4.1.1 Parsing. You can read about both versions at the W3C’s Web Accessibility Initiative.

For a Title II project, we report against WCAG 2.1 AA, since that is what the rule references. We also note, separately, how the site does on the newer 2.2 items such as the new target size criterion (2.5.8), the check that focus is not hidden behind sticky bars (2.4.11) and Redundant Entry (3.3.7). Those are good practice and often cheap to fix while we are already working on a template. And because 4.1.1 is gone from 2.2 but still part of 2.1, we check the markup problems it was written for when the reference version is 2.1.

What does AA look like on a public site? A resident using only a keyboard can open the “Departments” menu and reach the trash pickup schedule (2.1.1). A blind resident hears “Pay water bill, button” instead of “button” (4.1.2). Someone with low vision can enlarge text to 200 percent without words getting cut off (1.4.4), and read the meeting agenda on a narrow screen without scrolling sideways (1.4.10). A form tells you which field you missed, in words (3.3.1).

What our ADA Title II website compliance support covers

We work on WordPress sites, including multisite networks where each department or school has its own subsite. A typical project includes:

• Inventory. A map of what is on the site: templates, page types, forms, embedded tools, documents, video, and which department owns each.
• Audit. Automated scans across the inventory, then manual testing by keyboard, with NVDA and VoiceOver, and at zoom and narrow widths, against WCAG 2.1 AA. Our accessibility audit service page describes the method.
• Template and theme fixes. Menus, headers, footers, search, focus styles, skip links and color contrast, fixed once at the source so every page benefits.
• Form fixes. Labels, instructions, error messages and CAPTCHA alternatives on permit requests, public records requests, job applications and contact forms. See the accessible web forms service for detail.
• Document and media work. Triage of PDFs, conversion of key documents into web pages, and caption checks on meeting video.
• Vendor review. Testing of embedded third-party portals and a written list of barriers to send to each vendor.
• Staff guidance. Short, practical instructions for the department editors who post content every week.
• Ongoing checks so new content and plugin updates do not reverse the progress.

Agendas, minutes, permits and other posted documents

On most public websites, documents are the biggest single backlog. Council packets, budgets, ordinances, bid notices, library event flyers, school board minutes, forms to print and sign. Many were scanned from paper, which means a screen reader sees a picture of text and nothing else.

Trying to fix every old file at once usually stalls a project. We sort documents into groups instead:

• Documents people need to use a service, such as application forms, fee schedules and instructions. These come first.
• Documents posted regularly from now on, such as agendas and minutes. Fix the template and the process, so every new one is accessible from the start.
• Documents that work better as a web page. A two-page notice or a program description is easier for everyone as ordinary HTML, and easier to keep accessible.
• Older material that few people use. How the rule treats it depends on its exceptions and their conditions, which is a question for your counsel; on our side, we list these files and their state so the decision is informed.

For the hands-on side of PDFs, including tagging and when to convert, see our guide to making PDFs on a website accessible. If staff upload documents through the media library, our walkthrough on adding a PDF to WordPress is a useful reference for how links and embeds behave. Video of public meetings needs accurate captions too; automatic captions are a starting point that someone should edit, as explained in captions for website video. Our media and document accessibility service covers caption review and PDF remediation as a project of its own.

Payment portals, permit systems and other vendor platforms

A resident does not care which company built the page where she pays a parking ticket. To her it is the city’s website. Utility billing, court payments, recreation sign-ups, permit applications, library catalogs, learning management systems and agenda software are often run by outside vendors and linked or embedded from your site.

How the rule treats services delivered through a vendor is something your counsel should explain. Practically, do not assume a portal is someone else’s problem. What we do:

1. List every third-party tool a resident might use from your site.
2. Test the main task in each one, by keyboard and with a screen reader: pay a bill, register for a class, search the catalog.
3. Write up the barriers found, with the WCAG 2.1 AA criterion for each, in a form you can forward to the vendor.
4. Suggest asking each vendor for an Accessibility Conformance Report, the document a VPAT template produces, and compare its claims with what testing actually showed.
5. Note interim alternatives, like a phone line or an accessible form, where a barrier cannot be fixed quickly.

When a contract comes up for renewal, those findings give your purchasing team concrete accessibility requirements to put in the next one.

Planning the work by priority when the list is long

A first audit of a public site can produce hundreds of findings. That is normal, and it is not a reason to freeze. We help you sort the work into tiers, so the first months go where residents feel it most.

Priority	What goes here	Examples on a public site
1: Core services	Tasks residents must complete to get a service or meet an obligation	Paying a utility bill, applying for a permit, registering a child for school, requesting records
2: Site-wide templates	Problems repeated on every page, fixed once in the theme	Keyboard menus, skip link, focus outline, footer contrast, search box label
3: High-traffic information	Pages many people read	Trash schedule, hours and locations, emergency alerts, public meeting calendar
4: New content process	Habits and templates for what gets posted from now on	Agenda template, editor guidance, caption step for meeting video
5: Older and low-use material	Content that needs a decision before work	Old newsletters, superseded plans, scanned historic records

Your counsel may adjust this order based on how they read the rule’s requirements and exceptions. The table is a technical starting point, not a legal ranking.

How a project runs inside a public organization

Public bodies have more people to coordinate than a small business. A project usually runs like this:

1. Kickoff with the site owner, often IT, communications or the clerk, to agree scope, departments and the people who sign off.
2. Inventory and audit of templates, forms, documents and vendor tools.
3. Prioritized plan shared with leadership and counsel.
4. Fixes on staging, with each change retested before it goes to the live site.
5. Department sessions so editors know how to post accessible content.
6. Monthly cycle of rechecks, new content scans and progress reports through accessibility monitoring.

Editors who post for one department rarely need full administrator rights, and cutting those back reduces accidental damage. Our explainer on WordPress user roles shows how to give each person only what they need.

Records your organization keeps along the way

Public organizations get asked questions by residents, boards, auditors and the press. Being able to show the work matters. You receive:

• The site inventory, with owners for each section.
• The audit report, each finding tied to a WCAG 2.1 AA criterion, with 2.2 notes listed separately.
• A dated fix log: what changed, where, by whom and the retest result.
• A document register showing which files were fixed, converted, replaced or are awaiting a decision.
• A vendor register with each portal, the barriers found, what was sent to the vendor and any reply.
• Monthly progress reports that a board or council can read without a glossary.

None of these documents will state that your site complies with the Title II rule. They record what was tested against WCAG 2.1 AA, what was fixed and what remains; whether that meets your legal obligations is a conclusion for your counsel.

Many public bodies also publish an accessibility statement with a way to report barriers. We can draft a public accessibility statement that describes the effort honestly and avoids claiming the site is fully accessible.

To judge progress yourself, pick three core tasks, such as paying a bill, finding the next council meeting and submitting a records request, and try each one with the keyboard alone every month. Compare the open-items count in each report with the last. Numbers going down on core services matter far more than an overall automated score going up.

What we need from your web team and departments

• A WordPress administrator account for our team, plus hosting or server access, or a contact in IT who can deploy changes.
• A staging copy of the site, or permission to create one.
• A list of departments and the person who posts content for each.
• The list of vendor portals and embedded tools, with test accounts where possible.
• Any complaints or accessibility requests received from residents, which show where people are actually getting stuck.
• Procurement or contract details we need to work within, including any security or data handling requirements.
• Guidance from your counsel on priorities and how reports should be shared.

If you already pay a maintenance provider, the contract should say who handles accessibility after updates. Our article on what a website maintenance contract should cover lists the clauses worth checking.

Pitfalls public bodies run into

• Buying an overlay as the plan. A toolbar script cannot fix scanned PDFs, vendor portals or a menu built wrong in the theme.
• Waiting for a redesign. A new site that is a year away leaves residents with the current one until then. Fix core services now, and write WCAG requirements into the redesign brief.
• Treating it as an IT-only task. Most new barriers arrive through content: a flyer posted as an image, a table pasted from a spreadsheet, a video without edited captions.
• Ignoring the vendors. If residents pay or apply through a portal, an accessible homepage alone does not get them through.
• Relying on one automated score. Scans miss many barriers that only show up when a person tests with a keyboard or screen reader.
• Writing dates from a memo into plans without checking. Confirm dates on ada.gov and with counsel, since they depend on your population and can change.

Staffing the work, and questions for any vendor you consider

Most public bodies end up with a mix of internal and outside effort. A reasonable split looks like this:

Work	In-house staff	Outside specialist
Writing new content accessibly	Yes, after training	Writes the guidance and spot-checks
Converting simple PDFs to pages	Often	Handles complex or high-volume sets
Theme, plugin and form code	If you have a WordPress developer	Usually
Full manual audit and retest	Rarely	Yes
Vendor portal testing and write-ups	Sometimes	Usually

When you issue an RFP or talk to providers, ask:

1. Will you report against WCAG 2.1 AA specifically, and note 2.2 items separately?
2. How will you handle our document backlog, and how will you decide which files to convert?
3. Will you test the vendor portals residents use, and give us findings we can send to each vendor?
4. What does your manual testing involve, and which assistive technology do you use?
5. Do you train department editors, and what do they get to keep?
6. What wording will you use about the result? A provider that promises the site will be compliant with the rule is promising more than any vendor can.

Whoever you choose, keep the work tied to routine WordPress care so it lasts. Updates, new plugins and new staff will keep changing the site long after the first audit. You can see how this page fits alongside audits, forms, documents and monitoring on our accessibility services hub.