I get a lot of calls that start the same way: "We just found out we need to be 508 compliant and we launch in six weeks." That's a rough spot to be in, and it's almost always more expensive than it needed to be. The rules aren't unclear. Most teams just don't think about them until the end. This checklist is what I'd hand a project manager on day one.

What is Section 508?

Section 508 of the Rehabilitation Act requires federal agencies to make the information and communication technology they develop, buy, maintain or use accessible to people with disabilities. That includes websites, web applications, documents and software. It doesn't apply to vendors directly, but agencies have to buy accessible products, which is why federal contractors get asked about 508 conformance.

State and local governments, schools and nonprofits are usually covered by other laws, such as Section 504 and the ADA. Under the ADA Title II rule, state and local governments must make their websites and apps conform to WCAG 2.1 AA by April 2027 or April 2028, depending on their size.

Section 508 vs WCAG

The revised Section 508 standards, in force since January 2018, incorporate WCAG 2.0 Level A and AA for web content, electronic documents and software. WCAG 2.1 keeps every 2.0 criterion and adds more, mostly for mobile, low vision and cognitive accessibility. If you build and test to WCAG 2.1 AA, you cover the 508 web requirements and the ADA Title II standard at the same time.

The 508 compliance checklist

Before you build

  • Put accessibility in the scope document as a requirement, and name the standard: WCAG 2.1 AA.
  • Ask vendors for an Accessibility Conformance Report (ACR) for any product you're buying.
  • Choose a component library with accessible patterns, or budget to build them.

During every sprint

  • Run axe-core or Lighthouse in CI. Automated tools only catch some issues, such as low contrast, missing alternative text and heading problems, but they catch them early.
  • Tab through every new feature using only the keyboard. Can you reach everything, see where focus is, and get out of every dialog?
  • Check contrast: at least 4.5:1 for normal text, and 3:1 for large text, icons and form field borders.
  • Give every meaningful image alternative text, and give decorative images an empty alt attribute.
  • Label every form field, and write error messages that say what went wrong and how to fix it.
  • Caption videos and provide transcripts for audio.

Before launch

  • Test your key tasks with a screen reader: NVDA on Windows, VoiceOver on Mac and iPhone.
  • Zoom to 200% and narrow the window to 320 pixels. Nothing should be cut off or need sideways scrolling.
  • Check the PDFs and other documents you publish. They're covered too.
  • Publish an accessibility statement with a way to report problems.

Every year

  • Get an independent audit, and retest after major releases.
  • Update your ACR if you sell to federal agencies, schools or state and local governments.

Why early beats late

Retrofitting accessibility after launch is brutal. You're not just tweaking colors and adding alt text. You're reworking user flows, rewriting content and retesting everything. I've seen it cost three to ten times what it would have cost to build it right from the start.

What I tell clients: bake accessibility checks into every sprint review, keep a style guide of accessible component patterns so your team isn't reinventing the wheel, and budget for an outside audit once a year. Once it's part of how your team builds, the whole product gets better, not just for people using screen readers.

Need help? We run accessibility audits and Section 508 testing and write Accessibility Conformance Reports.