We Tested Our Own Website Against the Accessibility Standard Cities Now Have to Meet

Our own site, tested first

On 2026-10-07 we tested innovationnexus.com against WCAG 2.1 Level AA, the accessibility standard the US Department of Justice now applies to state and local government websites. Here is what we found, what we fixed, and what we have not finished.

Why a city should care

In 2024 the Department of Justice adopted a rule under Title II of the Americans with Disabilities Act that requires a city's web content and mobile apps to meet WCAG 2.1 AA (28 CFR 35.200). In April 2026 an interim final rule moved the compliance dates back one year: April 26, 2027 for cities and counties of 50,000 people or more, and April 26, 2028 for smaller ones and for special districts. The standard itself did not change. The rule also covers content a city provides through someone else, such as a contractor that builds or runs a site or dashboard for it. So when a city hires a firm for that work, the city's obligation travels with the contract, and it is fair for the city to ask the firm to show its own house is in order first.

What the rule means for a city's vendors

The Department of Justice's own fact sheet says the rule applies "when a state or local government has an arrangement with someone else who provides or makes available web content for them." In practice that reaches further than the main city website. A utility billing portal, a permit lookup, a budget dashboard, an online payment page or a public meeting video can all be web content the city provides through a vendor. If any of those fails the standard, the obligation still sits with the city. That is why a city's procurement and IT staff are starting to ask vendors for proof of accessibility testing, not only a promise. It is also why we think a vendor should be able to show its own work first.

What we tested

We ran axe-core, an open source accessibility testing engine, in a headless browser against every page in our sitemap except the blog, plus 12 blog posts that share one template: 61 pages in all. We also checked that pages reflow at a 320 pixel width, as on a small phone.

What we found and fixed

The first scan was not flattering. Link colors failed the contrast minimum on every page, more than 3,000 elements in total. The contact form, which is how cities have reached us, had fields that were not tied to their labels, and a screen reader user would not have heard whether a message was sent. There was no "skip to main content" link. We fixed all of it in five changes over the same day, re scanned the live site after each one, and finished at zero violations across all 61 pages, with the skip link as the first stop on every page. Tests now run on every change, so a regression fails our build before it reaches the site.

How we tested

The scan is repeatable, which matters more than any single result. We list every page in the sitemap, load each one in a real browser engine without a screen, and run axe-core against the rendered page, so the test sees what a visitor sees after scripts run. We then re-run the same scan against the live site after each fix, rather than trusting the change on a developer's machine. The results are saved with the date, so the next scan can be compared with this one line by line. Automated axe checks now also run in our test suite whenever we change the site, which is how we keep a fixed problem from coming back quietly.

What each fix changes for a visitor

Numbers like "3,000 elements" hide what a failure means for a person, so here is each fix in plain terms. Low contrast links are hard to read for anyone with low vision, and for everyone on a phone in sunlight; WCAG asks for a contrast ratio of at least 4.5 to 1 for normal text, and our link color now meets it. A form field that is not tied to its label leaves a screen reader user hearing "edit text" with no idea what to type; each field now announces its own label. A form that does not announce its result leaves the same user wondering whether the message went anywhere; the form now reads out that it was sent, or that it failed. A skip link lets someone who uses a keyboard jump past the menu straight to the content instead of pressing Tab through every navigation link on every page. None of these changes is visible to most visitors, which is exactly why they get missed.

What this does not prove

Automated tools catch roughly a third of accessibility problems. A scan cannot tell whether a screen reader user can actually complete a task, whether focus moves sensibly through a menu, or whether a page still works at 200 percent zoom. Those need a person. Our manual screen reader pass has not been done yet, so our accessibility statement still says partially conformant, and it will keep saying that until the manual pass is complete. That wording is accurate, not modest.

What our manual pass will check

The manual review has two parts. The first is a keyboard pass: on each page we press Tab from the top of the page to the footer and back. The first stop must be the skip link, every link and form field must be reachable exactly once, the focus outline must be visible at every stop, focus must follow the visual order, and nothing may trap the keyboard. Menus must open with Enter or Space and close with Escape. The contact form must be fillable and sendable with the keyboard alone. The second part uses NVDA, a free screen reader. On each page we check that the page title makes sense when it is read first, that headings come in a sensible order, that the main content and navigation are announced as landmarks, and that every link makes sense out of context, with no bare "read more." On the contact form, each field must announce its label and whether it is required, a missing field must be read out as an error, and a sent message must be confirmed out loud. When both parts pass, we will update our accessibility statement and say so here.

Three questions to ask any web or dashboard vendor

• What standard do you test against? A good answer names WCAG 2.1 Level AA, the standard in the Title II rule, and says whether testing covers every page or a sample.
• What did your last test find? A good answer gives a date, the tool used, what failed and what was fixed. "We are fully compliant" with no date or tool is not an answer.
• What have you not tested yet? A good answer names the gaps, usually manual keyboard and screen reader review, and says when they will be done. A vendor that claims no gaps has probably not looked.

Those are our answers

Whoever builds or runs a city's web content, those three questions sort a tested product from a promise. This post is our answer to all three. If you would like to see how we test a city's own site or dashboard, book a 15 minute call through our contact page. This post describes the federal rule for general information and is not legal advice. Sources: Federal Register, Extension of Compliance Dates, 2026-04-20 (91 FR 20902); ADA.gov, Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps.