Section 508 compliance

Section 508 of the Rehabilitation Act covers US federal agencies and the information and communications technology they develop, buy, or use. In practice it reaches much further. Any company selling software, websites, or digital documents to the federal government is expected to meet it, because agencies must weigh accessibility when they purchase, which is why vendors are routinely asked for conformance documentation before a contract is signed.

It is worth being precise about what creates the obligation. Section 508 does not regulate private companies directly. What reaches a vendor is procurement: the agency has a duty, so the requirement arrives in your RFP response, your security questionnaire, or your contract terms. That is also why the deadline is usually somebody else's, and always short.

The Revised 508 Standards, often called the "508 refresh", incorporate WCAG 2.0 Level A and AA by reference for web content. Because WCAG 2.1 and 2.2 are backward compatible, testing against WCAG 2.2 AA covers the 508 web requirements and a little more. A modern axe-core audit against WCAG 2.2 A and AA is therefore a sound way to check 508 web conformance.

Two things the WCAG mapping does not cover, and people miss both. The standards also carry functional performance criteria, which describe outcomes a user must be able to achieve without vision, without hearing, without fine motor control and so on, and they apply when the technical criteria do not fully address a feature. And support documentation counts: your help pages, PDFs and training materials are in scope, not just the application.

Grouped the way you actually work through it. The auto items are reliably settled by automated testing; the manual items need a person, whatever a tool's marketing says.

• Text alternatives (auto for presence, manual for quality): every meaningful image, icon and control has a text alternative, and decorative images are marked so screen readers skip them. A tool tells you alt text is missing. Only a person tells you it is useless.
• Colour and contrast (auto): normal text at 4.5:1, large text at 3:1, and meaning never carried by colour alone.
• Structure (auto): headings in a sensible order, lists and tables marked up as lists and tables, landmarks present, page language declared.
• Forms (auto for labels, manual for flow): every field programmatically labelled, errors identified in text, required fields indicated, and instructions not conveyed by placeholder alone.
• Keyboard operation (manual): every control reachable and operable without a mouse, no focus traps, a visible focus indicator, and a focus order that follows the visual layout.
• Screen reader behaviour (manual): names, roles and values announced correctly, dynamic updates announced, and custom widgets behaving as their role implies.
• Time and motion (manual): time limits adjustable, moving content pausable, nothing flashing beyond the threshold.
• Media (manual): captions for prerecorded video, audio description where needed, transcripts for audio.
• Documents (mixed): PDFs and Office files tagged, with reading order and alternatives. Frequently forgotten, and frequently the largest body of content an agency actually receives.
• Authenticated areas (mixed): the application behind the login, not only the marketing site. If the agency is buying the application, that is what has to be tested.

The WCAG 2.2 checklist covers the same criteria in WCAG's own grouping if you need to line the two up.

Automated testing reliably resolves roughly a third of the WCAG success criteria. That third is worth automating because machines are more consistent than people at it: contrast ratios, missing alternatives, unlabelled fields, heading order, ARIA misuse. It is also the third most likely to regress silently when somebody ships a style change.

The rest is judgement, and claiming otherwise is how a vendor ends up with a conformance report it cannot defend. Whether alt text is meaningful, whether focus order makes sense, whether an error message tells a user what to do: those need a human. A useful audit report says which bucket each finding is in instead of rolling everything into one score.

Federal buyers usually ask for a VPAT, and what they want back is the completed document, properly called an Accessibility Conformance Report. For 508 procurement, use the 508 edition of the template, or the INT edition if you also sell into the EU.

A scan does not produce that document, and no tool should claim to. What it gives you is the evidence base: a current, criterion-by-criterion record of what passes, what fails and what needs review, which is exactly what you reconcile against when completing the template. The practical mechanics are in how to fill out a VPAT.

The recurring failures are procedural rather than technical. Testing the marketing site when the agency is buying the application. Submitting a report against a product version you no longer ship. Ignoring the PDFs, which are often most of what the agency will actually publish. Marking every criterion as fully supported, which experienced reviewers read as a document nobody checked. And treating conformance as a one-time exercise, when the product changes weekly and the report does not.