5 Accessibility Fixes Any City Can Make This Week
You do not need a six-figure budget or an accessibility consultant to start fixing your city's website. The five issues below account for the majority of automated WCAG violations we find across government sites. Each one can be fixed in minutes, and each one makes a direct, measurable difference for the residents who depend on your web content. Here is exactly what to do, why it matters, and which WCAG criterion each fix satisfies.
Fix 1: Add Alt Text to Every Informative Image
WCAG Criterion: 1.1.1 Non-text Content (Level A)
Found on 89% of government sites we scan
What it is
Alt text is a short text description attached to an image via the alt attribute on the <img> tag. Screen readers read this text aloud so residents who are blind or have low vision understand what the image conveys. Without it, a screen reader either skips the image entirely or reads the file name, something like "IMG_4392.jpg," which tells the resident nothing.
Why it matters for residents
Imagine a blind resident visiting your parks department page. There is a photo of the new splash pad at Memorial Park with summer hours listed below it. Without alt text, the resident does not know the splash pad exists, does not know what it looks like, and has no context for the hours listed beneath it. They are excluded from information that every sighted resident takes for granted.
How to fix it
For every informative image, add an alt attribute that describes what the image communicates. Good alt text is concise and purposeful:
Good: alt="Children playing in the new splash pad at Memorial Park"
Good: alt="City Hall exterior, 100 Main Street"
For decorative images that add no information (background patterns, visual dividers, stock photos used for aesthetics), use an empty alt attribute: alt="". This tells screen readers to skip the image entirely, which is the correct behavior for decoration.
Fix 2: Fix Color Contrast Ratios
WCAG Criterion: 1.4.3 Contrast (Minimum) (Level AA)
Found on 84% of government sites we scan
What it is
Color contrast is the difference in brightness between your text and its background. WCAG requires a minimum contrast ratio of 4.5:1 for normal-sized text (under 18pt or 14pt bold) and 3:1 for large text (18pt+ or 14pt+ bold). Many government websites use light gray text on white backgrounds, blue text on dark blue headers, or low-contrast color combinations in buttons and navigation elements.
Why it matters for residents
Roughly 12 million Americans over age 40 have some form of vision impairment. Low-contrast text is difficult or impossible for them to read. It also affects anyone reading a screen in direct sunlight, anyone with aging eyes, and anyone experiencing screen glare. When your water bill payment instructions are in light gray text, you are creating a barrier for a significant portion of your residents.
How to fix it
Use a contrast checking tool. The WebAIM Contrast Checker is free and runs in any browser. Enter your text color and background color, and it will tell you the ratio and whether it passes WCAG AA. For most sites, the fix is straightforward: darken your grays, ensure your link colors have sufficient contrast against their backgrounds, and check that any text overlaid on images has enough contrast. Common fixes include changing #999999 text to #595959 or darker.
Fix 3: Add Labels to Every Form Field
WCAG Criterion: 1.3.1 Info and Relationships (Level A) & 4.1.2 Name, Role, Value (Level A)
Found on 76% of government sites we scan
What it is
Every input field in a form (text fields, dropdowns, checkboxes, radio buttons) needs a programmatically associated <label> element. Many developers use placeholder text inside the field as the only indicator of what information is expected. Placeholders are not labels. They disappear when a resident starts typing, leaving no indication of what the field is for. They are also not reliably announced by screen readers.
Why it matters for residents
A blind resident filling out your water service application form encounters a text field. Their screen reader says "edit text" and nothing else. They have no way of knowing whether the field expects their name, their address, their account number, or something else. Without labels, every form on your site becomes a guessing game for residents using assistive technology. This is also true for residents with cognitive disabilities who rely on persistent labels as reference points while filling out long forms.
How to fix it
Add a <label> element for every form field and connect them with matching for and id attributes. The label should be visible. Do not hide it. A visible label benefits everyone: sighted residents, screen reader users, residents with cognitive disabilities, and anyone filling out the form on a small mobile screen. You can keep placeholder text as a supplementary hint, but the label must be there and visible.
Fix 4: Add the Lang Attribute to Your HTML Tag
WCAG Criterion: 3.1.1 Language of Page (Level A)
Found on 52% of government sites we scan
What it is
The lang attribute on your HTML element tells browsers and assistive technologies what language your page content is in. It looks like this: <html lang="en"> for English. Without it, screen readers have to guess the language, which frequently results in garbled pronunciation that makes content unintelligible.
Why it matters for residents
A blind resident using a screen reader configured for English visits your site. Without the lang attribute, the screen reader might apply Spanish pronunciation rules, French pronunciation rules, or its default heuristic, any of which will make your English content sound like gibberish. For municipalities with multilingual content, the lang attribute on specific sections also ensures that Spanish-language pages are read with Spanish pronunciation.
How to fix it
This is a single line of code. Open your site's main template or layout file, find the <html> tag, and add lang="en" (or the appropriate language code). If your CMS generates the HTML tag, look for the language setting in your CMS configuration. Most modern CMS platforms have this option. For pages in other languages, use the appropriate code: es for Spanish, fr for French, and so on. This fix takes 30 seconds and immediately fixes a WCAG Level A violation on every page of your site.
Fix 5: Give Every Page a Descriptive Title
WCAG Criterion: 2.4.2 Page Titled (Level A)
Found on 48% of government sites we scan
What it is
The <title> element in your page's <head> section defines what appears in the browser tab and what screen readers announce when a resident first loads the page. Many government sites use the same title on every page ("City of Springfield" on every page) or use generic titles ("Page" or "Untitled Document") that tell the resident nothing about the content.
Why it matters for residents
Page titles are the first thing a screen reader announces when a page loads. They are how residents distinguish between multiple open tabs. A resident with 12 tabs open who hears "City of Springfield" on all of them has no way to find the water bill payment page versus the parks schedule versus the council meeting agenda. Descriptive titles like "Pay Your Water Bill - City of Springfield" orient residents immediately and save time for everyone, not just those using assistive technology.
How to fix it
Every page should have a unique, descriptive title that identifies both the page content and the site. A good pattern is: "Page Content - Site Name." For example: "Pay Your Water Bill - City of Springfield" or "Parks & Recreation Summer Programs - City of Springfield." Most CMS platforms automatically generate page titles from the page name or heading. Check your CMS settings to ensure this is configured correctly. If your CMS generates duplicate titles, it is usually a template configuration issue that can be fixed once and applied site-wide.
The Impact of These Five Fixes
These five issues account for the majority of automated WCAG violations on the government sites we scan. Fixing all five typically improves a site's automated readiness score by 15 to 30 points. More importantly, each fix removes a real barrier for real residents: a parent who cannot read the school lunch menu, a veteran who cannot submit a permit application, a senior who cannot pay their property taxes online.
These fixes are a starting point. They address the most common issues that automated scanning catches. AuditAble's scanning evaluates 28 of the 50 WCAG 2.1 AA success criteria today (33 when AI-assisted evaluation is enabled) and reports everything it did not test as Not Evaluated. A complete compliance effort requires testing the remaining criteria as well. But starting with these five gets you moving in the right direction, builds momentum with your team, and demonstrates to the DOJ that your entity is taking compliance seriously.
Find all five on your site in a few minutes
AuditAble's free scan checks for every issue in this article, plus dozens more. Paste your URL, see exactly which pages have which violations, and get a prioritized remediation list.
Get the Five Quick Wins Checklist as a PDF
The five most common government website accessibility fixes, with step-by-step instructions for developers and IT staff. Share it with your team or attach it to your remediation plan. No account required.