Atlas Business Management
Government IT Services/Technology Procurement/Business Advisory
AboutServicesManaged ITWeb DevelopmentMarketingAI AutomationProductsBuild a QuoteAdvisoryContractsBlogContactSupport
Government IT & Procurement

Section 508 Requirements for Government Websites

What Section 508 actually requires, how conformance is measured, and the failures that account for most of what auditors find.

Four colleagues gathered around a seated man at an open laptop, all smiling at the screen in a bright office

Section 508 of the Rehabilitation Act requires federal agencies to make their electronic information and technology accessible to people with disabilities. It applies to what agencies build and to what they buy — which is why it belongs in procurement rather than in a remediation project two years later.

What the standard actually points to

The 508 standards incorporate the Web Content Accessibility Guidelines (WCAG) Level AA for web content and software. So in practice, "is this 508 conformant?" means "does it meet WCAG AA?"

That matters because WCAG is testable. It is a specific list of success criteria, not a judgement call, and both you and a vendor can be held to it precisely.

The four principles, briefly

  • Perceivable. Information must be available to more than one sense — text alternatives for images, captions for video, sufficient colour contrast, and never colour alone to convey meaning.
  • Operable. Everything must work by keyboard. No time limits that cannot be extended. Focus must be visible and must not get trapped.
  • Understandable. Predictable navigation, labelled form fields, and error messages that say what is wrong and how to fix it.
  • Robust. Correct semantic markup so assistive technology can interpret the page — headings that are real headings, buttons that are real buttons.

The failures that account for most findings

In practice the same handful recur:

  1. Images without meaningful alt text — or decorative images given alt text that a screen reader then reads aloud pointlessly.
  2. Form fields with no programmatic label. Placeholder text is not a label; it disappears on focus and is often not announced.
  3. Keyboard traps. A modal a keyboard user can enter and cannot leave. Test by unplugging the mouse.
  4. Insufficient contrast, particularly grey secondary text and disabled states.
  5. Headings used for size rather than structure, which destroys the navigation screen reader users rely on.
  6. Custom controls built from generic elements with no accessible name or state. This is the most common failure in modern applications.
  7. PDFs. Frequently the largest single gap. A scanned PDF is an image and is entirely inaccessible; a generated one still needs proper tagging.

How conformance is documented

The instrument is an Accessibility Conformance Report, usually produced using the VPAT template. It states, criterion by criterion, whether the product supports the standard, partially supports it, or does not.

Two things buyers should know. First, a vendor writes their own — so a report claiming full support across every criterion with no caveats deserves more scrutiny, not less. Second, an honest report with documented exceptions and a remediation roadmap is a better signal than a flawless one, because it suggests someone actually tested.

Ask for it with the bid. Requesting it after selection is how agencies discover the problem too late to act on it — one of the reliable stalls covered in how agencies buy software.

Testing it yourself, cheaply

Automated tools catch perhaps a third of issues and are still worth running. Beyond that, three manual checks find most of the rest:

  • Unplug the mouse and complete a core task with the keyboard alone. Watch where focus goes and whether you can see it.
  • Zoom to 200% and check nothing is cut off or overlapping.
  • Turn on the screen reader built into the operating system and try the same task. Even ten minutes is revealing.

Build it in, do not bolt it on

Retrofitting accessibility into a finished application is expensive, and some of it — a component library with inaccessible foundations — cannot be fixed without rebuilding. Designing for it from the start adds relatively little, mostly in the form of using standard components properly and testing as you go.

That is why accessibility belongs in the requirements and in the acceptance criteria, not in a phase at the end. We build to WCAG AA as standard within application development, and it is a requirement worth writing into any statement of work you issue.

Need an existing system assessed? We can tell you where you stand before an auditor does.