In April 2024, the U.S. Department of Justice published a rule under Title II of the Americans with Disabilities Act about the web content and mobile apps of state and local governments (ADA.gov). If residents use it to get a city service, it's in scope. A 311 report page, a resident app and a request tracking page are clear examples.
This article is a plain summary for city staff. It isn't legal advice. Your city attorney should confirm how the rule applies to you.
The standard: WCAG 2.1 Level AA
The rule uses the Web Content Accessibility Guidelines (WCAG) version 2.1, Level AA, as its technical standard (ADA.gov). In everyday terms, that means things like:
- Every function works with a keyboard alone.
- Text has enough contrast against its background (4.5 to 1 for normal text).
- Images and icons that carry meaning have text alternatives.
- Forms have labels, and errors are explained in text.
- Pages still work when zoomed in or on a narrow screen, without scrolling sideways.
- Screen readers can tell what each control is and what state it's in.
The deadlines
The original rule gave governments three or four years, depending on size. In April 2026, the Department of Justice published an interim final rule extending those dates by about a year (Federal Register). The current dates are:
- April 26, 2027 for state and local governments serving 50,000 or more people.
- April 26, 2028 for those serving fewer than 50,000 people, and for special district governments.
The technical standard didn't change. The Justice Department also notes that governments still have an ongoing duty under Title II to make their services accessible in the meantime (ADA.gov).
Why 311 is a good place to start
A 311 system is often the most-used interactive service a small city offers. It includes maps, photo uploads, multi-step forms and status pages: exactly the kinds of features that are easy to get wrong. If your 311 system isn't accessible, a resident who uses a screen reader may not be able to report a broken sidewalk, which is exactly the kind of problem that affects them most.
How we build Sentra 311
Accessibility is part of how every Sentra 311 screen is built and checked:
- Automated checks on every screen. Our test suite runs accessibility scans (axe-core, for WCAG 2.1 A and AA rules) on the resident pages, the staff portal in light and dark mode, the marketing site and the apps. A failing scan fails the build.
- Keyboard tests. Key flows, such as reporting a problem and working the queue, are tested with the keyboard alone.
- Reflow at 320 pixels. Pages are tested on a narrow phone screen for sideways scrolling.
- Maps with alternatives. Map pins have labels, and the information shown on maps is also available as text and tables.
- Large targets. Buttons in the worker and resident apps are at least 44 pixels tall, and most are 56.
Automated tests catch many problems, but not all. Testing with screen readers and other assistive technology fills the gap, and a published Voluntary Product Accessibility Template (VPAT), prepared with our sister product GOVvpat, is on our roadmap.
Questions to ask any 311 vendor
- Which WCAG version and level do you test against?
- Do you test automatically on every release, or once a year?
- Can I see a current VPAT or accessibility conformance report?
- Are the resident report form, the tracking page and the mobile app all covered?
- How do you handle maps for screen reader users?
- If a resident reports an accessibility problem, how fast do you fix it?
Common problems we design around
A few issues come up again and again in civic software:
- Maps that only work with a mouse. Every action available on a map should also be available another way, such as an address search or a list.
- Photo upload buttons without labels. Screen reader users hear "button" and nothing else.
- Status shown only by color. A red dot means nothing to someone who can't see red. Status needs a word, too.
What the city still owns
Your vendor can make the software accessible. The city still owns its content: the request types you name, the questions you add to forms, the knowledge base articles you write and the photos you publish. Write plainly, describe what matters in photos, and avoid instructions like "click the red button" that depend on seeing color.