Section 508 Compliance Checklist for Government Websites

Most government web teams know Section 508 compliance is required. Fewer know exactly what to check. The standard is WCAG 2.0 Level AA, organized around four principles that cover everything from image alt text and video captions to keyboard navigation and form labels. This checklist walks through each one in plain language.

If your agency is working toward Section 508 compliance, the hardest part isn't understanding that it's required. It's figuring out what it actually looks like on a live website.

This checklist takes the WCAG 2.0 Level AA standard and breaks it into plain-language requirements your team can actually use. If you want the full background on Section 508 and who it applies to, it's covered here.

Free tools like WAVE, Google Lighthouse, and Axe are worth running. They catch obvious issues quickly and give you a good starting point. But don't stop there.

The truth is, automated scanners catch somewhere between 30% and 57% of real accessibility issues depending on the tool. While they can tell you whether an image has alt text, they can't tell you whether that alt text actually describes the image in a way that's useful to someone who can't see it.

That's a meaningful gap.

After you run an automated scan, test manually. Tab through your pages using only a keyboard. Open a screen reader and listen to how your most important pages actually sound. Check every PDF your agency links to. That's where the rest of the issues live.

This covers whether users can see, hear, or read everything on your site, regardless of ability.

• Every meaningful image has alt text that describes what it shows or communicates. Decorative images have empty alt text so screen readers skip them.
• All pre-recorded video has accurate captions. Auto-generated captions that haven't been reviewed don't meet this requirement.
• Audio-only content, like a recorded public meeting, has a text transcript.
• Page structure is coded properly, not just formatted to look structured. Headings, lists, and tables need to be real HTML elements.
• Text has sufficient contrast against its background. The minimum is 4.5:1 for normal text and 3:1 for large text. WebAIM's free Contrast Checker can verify this.
• Color is never the only way to convey information. Error messages and required fields need a second signal beyond color.

This covers whether users can interact with your site, regardless of how they access it.

• Every function on the site works using a keyboard alone. If something requires a mouse, it fails.
• Keyboard focus never gets trapped. Users can always tab in and out of any component.
• There's a skip navigation link at the top of every page so keyboard users can jump to the main content without tabbing through the entire menu first.
• Every page has a unique, descriptive title that tells users where they are.
• The keyboard focus indicator is always visible. When someone tabs to a link or button, they can see where their focus is.
• Link text describes the destination or action. 'Click here' and 'Read more' fail. 'Read the permit application guide' passes.
• No content flashes more than three times per second.

This covers whether users can understand your content and predict how the site will behave.

• The page language is declared in the HTML so screen readers use the right pronunciation.
• Navigation appears in the same location on every page.
• Every form field has a visible label. Placeholder text inside the field doesn't count.
• Error messages tell users specifically what went wrong and how to fix it. 'Invalid entry' fails. 'Please enter a valid email address' passes.
• For forms that involve legal or financial submissions, users can review and correct their input before submitting.

This covers whether your code is sufficiently clean to work reliably with screen readers and other assistive technologies.

• The HTML is valid. Errors like duplicate IDs and missing closing tags can cause screen readers to misinterpret the page.
• Every button, link, and form field has an accessible name that a screen reader can announce.
• Custom-built components that behave like standard elements use ARIA attributes to communicate their role and state to assistive technology.

Government websites link to a lot of PDFs. These include meeting agendas, permit applications, public records, annual reports, and more. And every one of them is a separate accessibility requirement.

A PDF created by scanning a paper document is an image, not text. A screen reader can't read it. Even PDFs exported from Word can have tagging, reading order, and alt text issues that make them inaccessible.

Start with the PDFs residents use most often, forms, agendas, and permit applications, and work from there. A PDF that can't be read by a screen reader isn't accessible, regardless of how the rest of your site performs.

Getting to compliance is one thing. Staying there is another.

Accessibility breaks when content changes. A staff member uploads an untagged PDF. Someone adds an image without alt text. A new page gets built with a heading structure that looks fine on screen but reads as a jumbled mess to a screen reader. And if your agency is still working toward ADA Title II compliance, the clock is still running. The DOJ extended the original deadlines in April 2026, but those new dates are firm. Large entities with populations of 50,000 or more must comply by April 26, 2027. Smaller entities and special districts have until April 26, 2028.

The most practical way to stay on track is to make accessibility part of your regular content process, not a separate annual project. That means training your staff, scheduling regular reviews, and giving residents a clear way to report issues.

At White Whale Web, every civic site we build includes staff training, an accessibility statement, and a content editor checklist so your team knows what to do from day one.

Remediation after the fact is almost always more expensive and more disruptive than building accessibly from the beginning. If you're planning a new government website or trying to close gaps on an existing one, we'd love to help. Reach out to our team anytime.