If your business builds websites, apps, online forms, booking tools or payment systems for cities, counties, school districts, transit agencies or other public bodies, a federal rule published in April 2024 affects your work, even though it is not addressed to you.

The U.S. Department of Justice’s final rule on web and mobile app accessibility under Title II of the Americans with Disabilities Act sets a specific technical standard for state and local governments. Those governments are responsible for compliance. But much of the content they publish is designed, hosted, managed or supplied by private companies. This article explains what the rule says that matters most to vendors, as it was published in 2024, and how agencies, designers and developers can prepare. It is not legal advice, and anyone with specific obligations should consult a qualified professional.

The rule in brief

The Department of Justice published its final rule on the accessibility of web information and services of state and local government entities in the Federal Register on April 24, 2024, effective June 24, 2024. It adopts the Web Content Accessibility Guidelines version 2.1, Level AA, as the technical standard.

The rule covers web content and mobile apps that public entities provide or make available, and the key phrase for vendors follows: directly or through contractual, licensing, or other arrangements. Content does not escape the rule because a contractor built it or a licensed platform delivers it.

Compliance dates, as published in the 2024 rule, depend on the size of the public entity: April 24, 2026 for entities with a total population of 50,000 or more, and April 26, 2027 for smaller entities and special district governments.

Why vendors should read the fact sheet

The Department’s fact sheet on the new rule, dated April 8, 2024, summarizes the requirements in plain language. Several examples speak directly to private companies working with governments:

  • If a county web page lists the addresses and hours of all county parks, that page must meet WCAG 2.1 Level AA even if a local web design company made the page and updates it for the county.
  • If a city lets people pay for parking with a mobile app, that app must meet WCAG 2.1 Level AA even if a private company runs it.
  • Content developed by outside technology companies, such as calendars, scheduling tools, maps, reservation systems and payment systems, generally needs to meet the standard because it is posted by the government.
  • Content that a company posts on a government’s behalf when it designs, manages or updates the website generally needs to meet the standard as well.

The fact sheet also notes that state and local governments that contract with other entities to provide public services must make sure their contractors follow Title II.

In short, from the government’s point of view, a vendor’s work is the government’s content. Agencies will increasingly need vendors who can show that what they deliver meets the standard.

What WCAG 2.1 Level AA means in practice

The WCAG 2.1 Recommendation, published by the W3C in June 2018, is organized into success criteria at three levels, A, AA and AAA. Level AA conformance means meeting all Level A and Level AA criteria.

Two conformance requirements are especially relevant to vendors:

Full pages. WCAG says conformance is for full web pages only and cannot be achieved if part of a page is excluded. An embedded widget that fails can affect the whole page it sits on.

Complete processes. When a page is one of a series presenting a process, such as an application, booking or payment, all pages in the process need to conform. A city’s form might be accessible, but if the payment step supplied by a vendor is not, the process is not.

That is why components matter so much. A single inaccessible date picker, map, chat window or payment frame can undermine an otherwise accessible site.

Hands in cyan sleeves press keys on a laptop beside a yellow notepad and a red pen.

The exceptions, and what they do not cover

The rule includes limited exceptions, which the fact sheet summarizes. Vendors should understand them because clients may ask whether content falls outside the standard:

  • Archived web content created before the compliance date, kept only for reference, research or recordkeeping, kept in a special archive area, and not changed since it was archived.
  • Preexisting conventional electronic documents, such as PDFs, word processing files, presentations and spreadsheets, available before the compliance date. Documents still used to apply for, access or participate in services do not qualify.
  • Content posted by third parties who are not acting for the government, such as a member of the public posting on a message board. The platform itself is not exempt, and content posted by a contractor is not third-party content in this sense.
  • Individualized, password-protected documents about a specific person, property or account.
  • Preexisting social media posts made before the compliance date.

Each exception has conditions, and the fact sheet stresses that governments still have obligations to provide effective communication and reasonable modifications. For vendors, the practical point is that new tools, templates, forms and current documents are generally in scope.

Other details worth knowing

Separate accessible versions are limited. The fact sheet explains that governments usually should not keep an inaccessible main page alongside a separate accessible version. Conforming alternate versions are allowed only where a technical or legal limitation prevents the main content from being made accessible. A “text-only” alternative is not a general workaround.

Minor failures. The rule addresses noncompliance with minimal impact on access. The fact sheet’s example is text with a contrast ratio of 4.45:1 against a requirement of 4.5:1, where the government may be able to show the difference does not affect access. This is a narrow provision, not a tolerance for sloppy work, and the fact sheet says governments cannot use it to avoid trying to meet the standard.

Mobile apps count. Apps provided or made available by public entities are covered alongside websites.

What agencies are likely to ask vendors

As compliance dates approach, procurement documents and contracts are likely to include accessibility expectations. Vendors should be ready for questions such as:

  • Does your product or service meet WCAG 2.1 Level AA, and how do you know?
  • What testing do you perform, and can you share results?
  • Which known issues exist, and what is the timeline to fix them?
  • How do you ensure new releases do not introduce barriers?
  • Who is responsible for content your staff publishes on our behalf?
  • How do you handle accessibility complaints from the public?

Vague answers such as “we follow best practices” are unlikely to satisfy a public entity that carries legal responsibility for the result. Clear, honest answers, including about known gaps and realistic timelines for fixing them, tend to build more confidence than broad claims of full compliance.

A man in a red jacket holding a white cane listens to his phone beside a blue car on a tree-lined street.

Practical steps for vendors

Inventory what you deliver to public clients. List websites, templates, components, plugins, documents, apps and hosted tools, and note which clients use each.

Test against WCAG 2.1 Level AA. Combine automated checks with manual testing, including keyboard-only use, screen reader checks, zoom and reflow, and color contrast. Test complete processes, not just individual pages.

Fix shared components first. Templates, navigation, forms, date pickers and payment steps affect many pages at once.

Document your work. Keep a record of what was tested, how, when, what was found and what was fixed. Many public entities will want evidence rather than assurances. Keep the records organized by client and product so they can be shared quickly.

Build accessibility into delivery. Include it in design reviews, development standards, quality checks and release processes. Thoughtful UI/UX design considers keyboard use, focus, labels and contrast from the start.

Check mobile carefully. Many residents use phones to pay bills, find services and check schedules. Layouts that reflow properly and controls that work at small sizes are essential, which is where responsive designs make a difference.

Train staff who publish content. Content editors at agencies or vendors need to know how to write headings, link text and alternative text, and how to create accessible documents.

Review third-party tools you embed. If you include a map, calendar, video player or chat tool from another supplier, ask for its accessibility information and test it in context.

Practical steps for agencies working with vendors

  • Write accessibility requirements, including WCAG 2.1 Level AA, into contracts and procurement documents.
  • Ask for testing evidence before accepting deliverables.
  • Plan reviews of existing vendor-supplied tools well before your compliance date.
  • Prioritize high-use services such as payments, applications, schedules and emergency information.
  • Provide a way for the public to report problems and route those reports to the right vendor.

A fictional example

Consider an invented small software company that supplies an online booking tool to several park districts for reserving picnic shelters. The districts embed the tool on their websites and link to it from their mobile apps.

Under the rule as described in the fact sheet, that booking tool is part of what the districts provide to the public. If a resident who uses a screen reader cannot choose a date because the calendar only works with a mouse, or cannot complete payment because the final step traps keyboard focus, the district has a problem, and so does the vendor’s relationship with that client.

A prepared vendor would test the full booking process against WCAG 2.1 Level AA, fix the calendar and payment steps, document the results, and give each district a clear summary of what was tested and any remaining issues with planned fixes. That summary becomes a selling point when contracts are renewed.

Questions to ask your own suppliers

Many vendors rely on components from others: themes, form builders, payment processors, map services and video players. Ask each one which accessibility standard it targets, what testing it has done, how it reports known issues, and how quickly it fixes them. Your client’s compliance can depend on answers several layers down the supply chain.

A note on timing

Two or three years can sound like plenty of time, but procurement cycles, redesigns and system replacements often take longer than expected. Vendors who prepare now will be better placed when agencies begin requiring proof, and agencies that start early will have more options if a vendor’s product cannot be fixed.

The bottom line

The 2024 Title II rule makes state and local governments responsible for accessible web content and mobile apps, including what they provide through contracts, licenses and other arrangements. For private companies serving those governments, accessibility is becoming a basic requirement of the work. WCAG 2.1 Level AA is the benchmark, complete processes and embedded tools matter, and documentation will increasingly be expected.

If you build or maintain digital services for public entities and want to review them against WCAG 2.1 Level AA, Motta Industries’ website accessibility team can help test, prioritize and fix what matters most.