Government WordPress sites fail WCAG 2.1 AA in the same six places nearly every time: text contrast, images without alt text, forms without labels, links and buttons with no name, menus and sliders that need a mouse, and PDFs that are pictures of text. Four of the six are set once in the theme or a plugin, which is why a site with 900 pages usually needs a fix in a dozen files, not 900.
The six failures on almost every site
WebAIM has scanned the home pages of the top million websites every year since 2019. The 2026 report found detectable WCAG 2 failures on 95.9 percent of them, and six failure types accounted for 96 percent of all errors found (WebAIM Million, 2026). Government sites are not in a separate category. If anything they skew worse, because the sites are older, the themes were bought once and never touched, and the content is posted by people whose job is not the website.
| Failure | Share of home pages (WebAIM, 2026) | Where it lives on a WordPress site |
|---|---|---|
| Low contrast text | 83.9% | Theme colours, button styles, links |
| Missing alt text on images | 53.1% | Media library, page builder image blocks |
| Missing form input labels | 51% | Form plugin, search widget, newsletter box |
| Empty links | 46.3% | Icon-only social links, image links with no alt |
| Empty buttons | 30.6% | Icon-only search, menu toggle, slider arrows |
| Missing document language | 13.5% | Theme header (rare on WordPress, common on static pages) |
Those are only the failures a scanner can see. Keyboard traps, focus order, reading order in PDFs, caption accuracy and whether error messages get announced take a person to find. The ADA Title II rule measures all of it, which is why the automated score is a starting point rather than a result. Our ADA Title II overview covers who the rule reaches and by when; this post is about where the sites fail.
Contrast is set once in the theme
Low contrast is the most common failure on the web and the cheapest to fix, and on WordPress it is almost always a theme setting. Grey body text at #767676 on white passes at 4.5:1; the #999999 that many themes ship with does not. Light blue links on white, gold on cream, and white text over a hero photo all fail. Government sites add a specific version: the city's brand colours, chosen decades ago for a letterhead, applied to buttons and links where they have never met 4.5:1.
The fix is a handful of CSS values in the theme or the Customizer, plus a rule for text over images (a dark overlay, or move the text off the image). Because it is set once, it repairs every page at the same time. Check it with the contrast checker built into Chrome's DevTools or WebAIM's contrast tool, and check the button hover states too; a button that passes at rest and fails on hover still fails.
Focus visibility belongs in the same fix. Many themes set outline: none on everything to make the design look cleaner, which means a keyboard user cannot see where they are on the page. WCAG 2.1 AA requires a visible focus indicator, and a two-pixel outline in a contrasting colour satisfies it.
Menus, sliders and calendars that need a mouse
A hover-only dropdown menu opens for a mouse and never opens for a keyboard. A hero slider auto-advances every five seconds with no pause button and arrows that are not in the tab order. An event calendar renders each day as a clickable cell with no keyboard path to it. These are the three keyboard traps on government sites, and each one is a plugin or theme component rather than page content.
Menus: most well-maintained themes now support keyboard navigation of dropdowns, but many older municipal themes do not. The test is simple. Put the mouse away, press Tab, and see whether you can reach every menu item and open every submenu. If not, the menu either needs its JavaScript patched or needs replacing with a block-based navigation menu, which handles this correctly.
Sliders: Slider Revolution and most hero sliders can be configured to stop auto-play and expose keyboard controls, but the default configuration fails both. The better answer on a government site is usually a static hero. Nobody is reading the third slide, and the rule requires that anything moving can be paused, stopped or hidden.
Calendars: The Events Calendar and similar plugins have improved, but the month view is still a common failure. The list view is usually accessible; make it the default and keep the month view as an option.
Mega menus built with a page builder are the hardest case, because the builder rendered the menu as nested containers with no semantic list structure. Those get rebuilt.
Forms depend on the plugin
Every government site has forms: contact, records request, service request, event registration, permit application. WCAG 2.1 AA needs a real label tied to each field, instructions before the resident makes a mistake, required fields marked in a way that is not only a colour, and error messages that a screen reader announces.
Which form plugin you use decides how much of this you get for free.
Gravity Forms has shipped accessible markup by default since version 2.5 in 2021, including labels, field descriptions tied to their inputs, and announced validation errors. WPForms is similar. Contact Form 7 gives you a text box to write the form's HTML in, so it is exactly as accessible as the person who built the form made it, which on most sites means placeholder text instead of labels. Forms built in Elementor's form widget land in between; the labels exist but the error handling needs attention.
The fix is rarely a rewrite. Most forms need labels turned on, placeholder text demoted to a hint, the asterisk supplemented with the word "required," and the error summary enabled. If the site uses Contact Form 7, the practical recommendation is to move the handful of forms residents depend on to Gravity Forms or WPForms and keep the licence on the maintenance plan. Our plugin audit guide covers how to find every form plugin on a site, including the ones nobody remembers installing.
Images and the flyer problem
Missing alt text is the second most common failure on the web and the one that content editors own. The media library makes it easy to add alt text and equally easy to skip. A city site with ten years of photos usually has thousands of images with none.
The scoped fix is not "add alt text to everything." Decorative images (the stock photo of a park bench) should have empty alt text so screen readers skip them. Meaningful images (the map of the road closure, the chart in the budget summary) need a description that carries the same information. Sorting the library into those two piles is most of the work.
Then there is the flyer. A department wants to announce the holiday schedule or the summer program, so someone designs a flyer in Canva and uploads the JPEG. To a screen reader it is a single image with no text. The rule does not have a flyer exception. Either the full text goes in alt text or, better, the announcement is posted as a page with the flyer as an illustration. This one failure is on nearly every school and parks site we look at, and it is a habit to change rather than a file to fix.
Page builders and heading structure
A screen reader user moves through a page by headings the way a sighted user scans by eye. WCAG 2.1 AA wants one H1, headings in order, lists marked up as lists and tables with header cells. Page builders break this constantly. A widget that styles text to look like a heading without using a heading tag, three H1s on one page because each section template had one, an H4 under an H2 because the H4 looked the right size.
The fix here is part theme, part training. Templates get corrected once. Editors learn that heading levels are structure, not font sizes, and that the block editor's outline view shows them the tree. On sites built entirely in a page builder, we sometimes find that moving the content types residents use most (news, meetings, alerts) to the block editor is faster than repairing every builder template.
Language is the easy one in the list. WordPress sets the page language in the theme header automatically, so a 13.5 percent failure rate across the web drops to near zero on WordPress, unless a custom theme stripped it out.
Video and captions
Council meetings, board meetings, public hearings, the mayor's update. If it is recorded and posted, it needs accurate captions. If it is streamed live, WCAG 2.1 AA needs live captions. YouTube's automatic captions are a starting point, but on a meeting recording full of names, motions, parcel numbers and vote counts they usually are not accurate enough to follow, and the rule measures accuracy.
The workable process for most entities is automatic captions corrected by a person before the recording is linked from the site, and a captioning service for live streams. Vendors that host meeting video often bundle this; it is worth asking what is already paid for.
How to check your own site in an afternoon
Run the home page, the contact page, the agendas page and one form through WAVE (the WebAIM browser extension) and Lighthouse in Chrome DevTools. Between them they catch contrast, alt text, labels, empty links and buttons, and heading order.
Then unplug the mouse. Tab through the same four pages. Can you reach every link, open every menu, submit the form, close the modal? Can you see where you are the whole time?
Then open NVDA on Windows (free) or VoiceOver on a Mac (built in), and listen to the home page and the form. This is where you find the "button" that has no name and the error message that never gets read out. The testing tools guide goes deeper on each tool.
Write down what you find, page by page, and sort it into theme, template and content. The theme pile is small and fixes everything; the content pile is large and is mostly alt text and flyers.
Fixing it without rebuilding the site
A government site that fails WCAG 2.1 AA in the usual six places almost never needs a rebuild. It needs the theme's contrast and focus styles corrected, the menu and slider made keyboard accessible, forms moved or reconfigured, headings straightened in the templates, a caption workflow, and a pass on the media library. That is a developer's project measured in days, plus a content habit change.
TopSyde does the review for free. A senior developer scans every page, works the pages residents use with a keyboard and a screen reader, and sends a written, ranked list. Fixes are quoted from that list. Afterwards, hosting and maintenance is $89/mo per site with no contract, and every update is tested on staging before it goes live, so a theme update cannot undo the contrast fix the board paid for. Details and the request form are on the ADA compliance page, and there are separate pages for cities and counties, school districts and special districts.
Frequently Asked Questions
Which WordPress themes are accessible out of the box?
Themes tagged "accessibility-ready" on wordpress.org have passed a review of keyboard navigation, focus styles, contrast and heading structure. The default Twenty Twenty-Five theme and most block themes from established vendors are in good shape. A theme being accessibility-ready does not make the site accessible; content, plugins and customizations can undo it. It does mean the theme pile of fixes starts small.
Is an automated accessibility scan enough to prove compliance?
No. Scanners find the failures that can be detected from the code, which is roughly the six in the table above. They cannot judge whether alt text is meaningful, whether the reading order makes sense, whether captions are accurate, or whether a keyboard user gets trapped in a modal. The ADA Title II rule measures conformance with WCAG 2.1 AA as a whole, so a clean scan is necessary and not sufficient.
Do we have to fix the school sites and the department sites too?
Yes. Every site a public entity provides or makes available is covered, including subsites on a multisite install and sites run by departments. The upside is that they usually share a theme, so the theme fixes apply to all of them at once. The content fixes, alt text and flyers, are per site.
How long does a WCAG 2.1 AA fix take on a typical city site?
For a site on a standard theme with a few forms and no page builder, the theme and template work is usually a few days of developer time. Page-builder sites and sites with large PDF libraries take longer, and the PDF work is often the biggest single item. The free review is the way to get a number for your own site rather than a range.
Topics
Senior WordPress Engineer
8+ years WordPress & WooCommerce development
Rachel is a senior WordPress engineer at TopSyde specializing in WooCommerce performance and plugin architecture. She has built and maintained high-traffic e-commerce sites processing millions in annual revenue.
