Government Website Accessibility Checklist

Every informational image must have an alt attribute that describes its content. Decorative images must have an empty alt attribute (alt="") so screen readers skip them. This includes staff photos, event banners, maps, charts, and logos.

Fix: Add descriptive alt text to every img tag. For decorative images, use alt="". For complex images like charts, provide a text description nearby or link to a data table.

Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) must have at least 3:1. Gray text on white, light blue on gray, and white on mid-tone backgrounds are the most common failures on government sites.

Fix: Use a contrast checker to verify all text colors. Common fix: darken gray body text from #999 to #555 or darker. Darken link colors to at least #0f2044 on light backgrounds.

UI components (form field borders, buttons, icons) and graphical objects that convey information must have a contrast ratio of at least 3:1 against adjacent colors. This was added in WCAG 2.1 and is frequently missed.

Fix: Ensure form input borders are visible (not light gray on white). Check that icons used for navigation or status have sufficient contrast. Focus indicators must be visible.

All prerecorded video with audio must have synchronized captions. This applies to council meeting recordings, press conferences, training videos, and any embedded YouTube or Vimeo content. Auto-generated captions are acceptable only if reviewed and corrected for accuracy.

Fix: Enable captions on YouTube/Vimeo. Review auto-generated captions for errors in proper nouns, technical terms, and municipal jargon. For critical content, use a professional captioning service.

Content must reflow to a single column at 320 CSS pixels wide (equivalent to 400% zoom on a 1280px viewport) without requiring horizontal scrolling. Data tables are exempt. This was added in WCAG 2.1 for users who zoom extensively.

Fix: Use responsive CSS layouts. Test by resizing the browser to 320px wide. Fix any elements that cause horizontal overflow. Avoid fixed-width containers wider than 320px.

Users must be able to increase line height to 1.5x, paragraph spacing to 2x, letter spacing to 0.12em, and word spacing to 0.16em without loss of content or functionality. If text clips or overlaps after these adjustments, the page fails.

Fix: Avoid fixed-height containers for text content. Use relative units (em, rem) instead of pixels for spacing. Test by applying the spacing overrides via browser developer tools and checking for text clipping.

Every interactive element (links, buttons, form fields, dropdowns, modals) must be operable using only a keyboard. Tab moves forward, Shift+Tab moves backward, Enter/Space activates buttons and links. This is the most critical accessibility requirement for motor-impaired users.

Fix: Tab through every page. If you cannot reach or activate an element, it needs a keyboard handler. Replace mouse-only events (hover menus) with keyboard-accessible alternatives. Never use tabindex values greater than 0.

When a user tabs to an element, there must be a visible focus indicator (outline, border, background change) that clearly shows which element has focus. Many government sites use CSS that removes the default browser focus outline (outline: none) without providing a replacement.

Fix: Never use outline: none or outline: 0 without a visible replacement. Add a high-contrast focus style: outline: 2px solid #0f2044 or a visible box-shadow on :focus-visible. Test by tabbing through the page.

The first focusable element on every page should be a "Skip to main content" link that jumps past the header and navigation. Keyboard and screen reader users should not have to tab through 20+ navigation links on every page to reach the content.

Fix: Add a visually hidden link as the first element in the body that becomes visible on focus. Point it to an id on the main content area. CSS: position:absolute, clip until :focus.

Every page must have a unique, descriptive title tag that identifies the page topic and the site name. Screen reader users hear the title first when a page loads. "Home" or a blank title forces them to explore the page to determine where they are.

Fix: Use the format "Page Topic - Site Name" (e.g., "Building Permits - City of Springfield"). Ensure no two pages share the same title. CMS templates should pull page titles automatically.

Link text must describe its destination. "Click here," "Read more," and "Learn more" are meaningless when read out of context by screen readers. Screen reader users often navigate by listing all links on a page, so each link must make sense independently.

Fix: Replace "Click here to view the agenda" with "View the March 2026 council meeting agenda." If redesigning link text is impractical, add an aria-label attribute that provides the full context.

Interactive elements should be large enough for touch users to activate accurately. While WCAG 2.1 AA does not set a specific minimum target size, best practice is at least 44x44 CSS pixels. WCAG 2.2 (Level AA, criterion 2.5.8) requires 24x24px minimum. Small links clustered together cause errors for users with motor impairments.

Fix: Add padding to links and buttons to increase the touch target. Ensure sufficient spacing between adjacent interactive elements. Test on a real mobile device by attempting to tap each element.

The html element must have a lang attribute declaring the page language (e.g., lang="en" for English). Screen readers use this to select the correct pronunciation engine. Without it, a Spanish screen reader might try to read English text with Spanish phonemes.

Fix: Add lang="en" (or the appropriate language code) to the opening html tag. For pages with content in multiple languages, use the lang attribute on specific elements containing foreign-language text.

Every form input must have a programmatically associated label element. Placeholder text is not a substitute for labels because it disappears when the user starts typing and is not reliably announced by all screen readers. This affects search boxes, contact forms, permit applications, and payment forms.

Fix: Add a label element with a for attribute matching the input's id. If a visible label is not desired, use a visually hidden label (not display:none, which hides it from screen readers too). Use aria-label only as a last resort.

When a form submission fails, the error must be identified in text, not just by color (a red border alone fails). The error message must describe the problem and, where possible, suggest how to correct it. Error messages must be programmatically associated with the input that caused them.

Fix: Display a text message near the invalid field (e.g., "Email address is required"). Use aria-describedby to associate the error message with the input. Move focus to the first error on submission failure.

Navigation menus must appear in the same relative order on every page. If the main navigation is "Home | Services | Departments | Contact" on one page, it must be the same order on every page. Inconsistent navigation forces users to relearn the interface on each page.

Fix: Use a shared header/navigation template across all pages. If the CMS supports global navigation components, use them. Audit all page templates to ensure navigation order is consistent.

Pages must use headings (h1-h6) in a logical hierarchy. There should be exactly one h1 per page (the page title). Subheadings should follow in order without skipping levels (h2 should not be followed by h4). Screen reader users navigate by heading, so a broken hierarchy makes pages harder to scan.

Fix: Audit heading structure using browser developer tools or a heading outline extension. Ensure one h1, sections under h2, subsections under h3. Never use heading tags for visual styling alone.

Pages should use HTML5 landmark elements (header, nav, main, footer) or ARIA landmark roles to define page regions. Screen reader users use landmarks to jump directly to the header, navigation, main content, or footer without tabbing through everything in between.

Fix: Wrap the site header in a header element, navigation in nav, primary content in main, and the footer in footer. If using custom elements, add role="banner", role="navigation", role="main", or role="contentinfo" respectively.

PDFs posted on government websites must be tagged for accessibility. This means proper reading order, tagged headings, alt text for images, and table headers. Scanned image PDFs with no text layer are completely inaccessible to screen readers. Government sites commonly post agendas, budgets, and ordinances as untagged PDFs.

Fix: Run PDFs through Adobe Acrobat's accessibility checker. Add tags, reading order, and alt text. For scanned documents, run OCR first to create a text layer. Consider posting HTML versions of critical documents alongside the PDF.

Every interactive element (buttons, links, inputs, custom widgets) must have an accessible name that assistive technologies can read. A search button with only a magnifying glass icon and no text or aria-label is announced as "button" with no indication of its purpose.

Fix: Add visible text labels to buttons. For icon-only buttons, add an aria-label attribute (e.g., aria-label="Search"). Ensure custom dropdown components have proper ARIA roles and labels. Test with a screen reader.