What Are the Most Common Accessibility Problems on Government Websites?
Six barriers turned up on most of the government websites Esther assessed over six months. Here is who each one stops, and how to spot it on your own site.
Rick Hensbergen4 minute read
A clerk asked whether the city's website is accessible usually wants a shorter answer first: what goes wrong most often? Over the past six months (April 19 to October 15, 2026), Esther assessed government websites and counted how many carried each barrier. Six turned up on more than seven in ten of them. Each one falls on a person you can name, and most can be spotted by someone who isn't a specialist.
The six, by how often Esther found them
- Text too faint to read comfortably: 98% of sites (WCAG 1.4.3, Contrast (Minimum))
- Menus, buttons, and dialogs a screen reader can't name: 95% (WCAG 4.1.2, Name, Role, Value)
- Form fields with no label, or only gray hint text: 83% (WCAG 3.3.2, Labels or Instructions)
- Form fields that don't tell the browser what they ask for: 81% (WCAG 1.3.5, Identify Input Purpose)
- Buttons and field borders too faint to see: 78% (WCAG 1.4.11, Non-text Contrast)
- Keyboard focus hidden behind a sticky header or banner: 72% (WCAG 2.4.11, Focus Not Obscured (Minimum), added in WCAG 2.2)
Faint text, and faint buttons
On 98% of sites, Esther found text too close in shade to its background to read comfortably. People with low vision meet it, and so does anyone reading a phone outdoors. On 78%, the same was true of the shapes people need to find: the border of a form field, the edge of a button.
The first look takes a phone and a sunny window. Light gray captions, form hints, and footer text are where faint text usually sits. A free contrast checker settles it: body text needs a ratio of 4.5:1 with its background, and buttons and field borders need 3:1.
Controls that a screen reader can't name
A screen reader speaks the page aloud. On 95% of sites, Esther found menus, buttons, or dialogs built without a name it can say, so where the control sits, the resident hears nothing useful. For people who are blind, that can be the main menu itself.
This check needs a screen reader, and every phone has one built in: VoiceOver on an iPhone, TalkBack on Android. With it on, the question is whether the main menu says what each item is when it's touched.
Form fields that don't explain what they want
On 83% of sites, Esther found form fields with no label, or with only the gray hint text inside the box, which disappears at the first keystroke. People who use screen readers or voice control are left guessing, and so is anyone who looks away mid-form. On 81%, fields for things like a name or an email address didn't tell the browser what they ask for, so autofill can't help the residents who rely on it.
The label check is typing. If the only clue to what a field wants vanishes once the first letter goes in, the barrier is there. The autofill gap sits in the page's code, so it takes an assessment or a developer's look to confirm.
Focus that disappears
People who use a keyboard instead of a mouse move through a page with the Tab key, and a visible outline shows where they are. On 72% of sites, Esther found that outline hidden behind a sticky header or a banner.
The check is the Tab key on a long page with a header that stays put. If the outline slides under the header and out of sight, the barrier is there.
Why the list is shorter than it looks
Barriers this common rarely start on the page where they're found. They come from a shared style or template, so one change clears every page built from it. How much work is it to fix website accessibility? shows how far that goes: on a typical site, almost all of 1,746 recorded barriers traced back to 34 distinct changes.
For state and local government, the Department of Justice's 2024 rule under Title II of the Americans with Disabilities Act (ADA) requires WCAG 2.1 Level AA: by April 26, 2027, for governments serving 50,000 people or more, and by April 26, 2028, for smaller governments and special districts. Five of the six barriers above are in WCAG 2.1. The sixth, focus hidden behind a header, was added in WCAG 2.2, and it stops keyboard users all the same.
What a finding is worth
A barrier you find this week is a fact about your own site, and it's worth writing down: the page, what you did, what you saw, and the date. That note is what a complaint or an attorney's letter asks about, usually without warning: what was found, when, and what has been resolved since. A record can't be made backwards. That is Esther's work: it finds the barriers on a site, ranks them by the urgency of what they block, and dates each one, so as issues are resolved the list gets shorter and the record shows when.
Four questions about your own site
- Can every line of text, and every button and field border, be read on a phone outdoors?
- With the phone's screen reader on, does the main menu say what each item is?
- When you type into a form field, does its label stay in view?
- When you press Tab down a long page, does the outline stay in sight?
A no to any of them is a finding. How to check if your website is accessible has three more checks that take minutes. What this means for a government: For government. For a private organization: For business.
Figures describe the government websites Esther assessed from April 19 to October 15, 2026, and give the share of sites where each barrier appeared.
About the author
Rick Hensbergen is the founder and CEO of Esther. He spent twenty years leading software testing and quality teams for major banks in the United States and the United Kingdom.