The Same Four Problems, Site After Site

Thirty sites in, a pattern emerges: it’s not that public sector and university websites have wildly different accessibility problems. It’s that they mostly have the same four.

As part of some benchmarking work ahead of the DOJ’s Title II deadlines, I’ve spent the last few months reviewing the sites of counties, cities, libraries, transit authorities, and regional universities across the country — different platforms, different vendors, different budgets. The assumption going in was that the findings would scatter: one site with a font-size problem, another with a form validation issue, another with something nobody’s seen before. Instead, the same handful of failures kept showing up, almost regardless of what the site was built on.

That’s not a coincidence. It’s a sign these aren’t one-off bugs. They’re structural.

Focus goes missing

The most common failure by far is also the easiest to miss if you’re not testing with a keyboard. A user tabs through a page, and at some point, the visual indicator of where they are simply disappears — swallowed by a low-contrast outline (often none at all), or lost entirely when a search panel or mobile menu opens on top of the page. The mouse user never notices, because the mouse doesn’t need a focus indicator. The keyboard user is left tabbing blind, with no way to tell whether they’re about to activate a “submit” button or jump to another section of the site.

This showed up on public agency sites and university sites alike, on both primary navigation and secondary widgets like filters and search panels. It’s rarely a one-line fix, but it’s also rarely intentional — it’s what happens when a component gets built and tested with a mouse, and never gets tested any other way.

Controls with no name

The second recurring failure is one automated tools like Axe and WAVE catch quickly, but the impact still falls hardest on the people those tools can’t speak for. A calendar’s next-month arrow, a set of social media links, a menu’s expand-collapse toggle all look perfectly clear to a sighted user. A screen reader user hears nothing useful, just “button,” with no indication of what the button does. Sometimes it’s worse than nothing, like a generic label that’s technically present but tells the user nothing.

This one is almost always a five-minute fix once it’s flagged — an aria-label, a visually-hidden span, a properly associated alt attribute. The fact that it’s cheap to fix and still shows up constantly says something about how rarely it gets tested for in the first place.

Keyboard dead ends

A step past focus getting lost is focus getting stuck. A subnav opens, and once a keyboard user is inside it, there’s no way back out to the page content they came from — the links inside the subnav work fine, but the exit doesn’t exist. A calendar widget lets a user move between months but never lets them land on and select a date without a mouse.

These are the failures that block task completion outright, not just create friction. A user who can’t select a date can’t register for the event. A user stuck inside a subnav has to refresh the page to get back to what they were reading. And because these widgets tend to get built once and reused across a dozen pages, one bad component becomes a sitewide problem instead of a page-level one.

The skip link that doesn’t work

The smallest and most avoidable failure on this list. A skip-to-main-content link that’s missing outright, or present in the markup but non-functional — a link that goes nowhere, or an anchor with no matching focusable target. It’s the very first thing a screen reader or keyboard user encounters on every page load, and when it’s broken, it’s broken everywhere on the site at once.

What the pattern means

None of these four problems require an unusual vendor, an unusual CMS, or an unusual level of complexity to produce. They showed up on sites built on entirely different platforms, run by entirely different teams, with entirely different budgets. That’s the finding underneath the finding: these aren’t the result of any one team cutting corners. They’re the default outcome of building and testing a site without a keyboard or a screen reader anywhere in the process.

Which is really the point. Thirty sites in, the problems aren’t random. They’re what happens when accessibility gets checked at the end instead of built in from the start — and the fix isn’t a one-off audit after launch, it’s catching these same four things before the site ever ships.