Section 508 website requirements: who they apply to and what to test

What Section 508 is

Section 508 of the Rehabilitation Act requires federal agencies to make their electronic and information technology accessible to people with disabilities when they develop, procure, maintain or use it. The Section508.gov site and the U.S. Access Board publish the standards and guidance.

The technical standard

The Revised 508 Standards are harmonized with WCAG 2.0 at Levels A and AA. The relevant text is in 36 CFR Part 1194, Appendix A (E205.4 for web content). WCAG 2.1 and 2.2 add further criteria, but Section 508 as written references 2.0.

Who it affects

• Federal agencies: directly responsible for the accessibility of their sites and technology.
• Vendors and contractors: affected through procurement. Agencies ask vendors for evidence such as a VPAT or accessibility conformance report when they evaluate technology.
• Private businesses: not covered by Section 508 directly. They are covered by ADA Title III, which has no fixed technical standard.

508 versus the ADA

Testing a site for 508

1. Run automated checks against the WCAG A and AA criteria. A scan finds the subset that automation can detect.
2. Test with a keyboard and with at least one screen reader, because most 508 test methods call for human testing.
3. Record results criterion by criterion, with the page and element, and what remains to fix.
4. Document the outcome in an accessibility conformance report if your customer asks for one.

What "ICT" means

Section 508 talks about information and communication technology, or ICT. That is a wide net: websites, web applications, software, mobile apps, electronic documents such as PDFs and slide decks, video and audio, hardware like kiosks and phones, and the documentation and support services that come with them.

The structure of the standards

The Revised 508 Standards sit in 36 CFR Part 1194, Appendix A, and are organized in a way that helps explain why testing involves more than a web scan.

• Scoping and application: which ICT must meet the requirements, and the exceptions.
• Functional performance criteria: statements such as "usable without vision" and "usable with limited reach" that every product should satisfy.
• Technical requirements: for web content, WCAG 2.0 Level A and AA; for software, hardware and documents, further specific requirements.
• Support documentation and services: help text, manuals and support channels must also be accessible.

Commonly cited exceptions

The standards include limited exceptions. Agencies apply them case by case and document the reason, so a vendor should not assume one applies.

• Undue burden or fundamental alteration, where meeting a requirement would be a significant difficulty or change the nature of the product.
• National security systems.
• Legacy ICT that existed before the standards took effect and has not been changed.
• Items not available in an accessible form in the market, where the agency documents what it did to look.

How federal buyers evaluate products

1. Define the requirement. The agency states what the ICT must do and which accessibility requirements apply.
2. Market research. The agency looks for products that meet them.
3. Request documentation. Vendors are usually asked for an Accessibility Conformance Report, commonly based on a VPAT. See VPATs explained.
4. Evaluate and, where needed, test. The agency checks the claims.
5. Contract. Accessibility requirements and the plan for fixing gaps are written into the contract.

Section508.gov publishes buying and testing guidance for agencies and for vendors who sell to them.

How testing is done for 508

Section508.gov describes a testing lifecycle: plan, scope, test, remediate and monitor. It supports automated, manual and hybrid approaches. The federal government's ICT Testing Baseline is a set of defined tests meant to make results consistent between testers, and the Interagency Trusted Tester Program trains and certifies people to apply it. See Section508.gov testing.

For a vendor, the practical point is that a federal reviewer may repeat your testing with a defined method. Results that were produced by an automated scan alone are unlikely to persuade them. Keyboard testing, screen reader testing and a record of what was tested and how are what a careful reviewer expects.

Documents, slides and video

Section 508 covers electronic documents, and government sites publish a great many PDFs. A few habits remove most problems.

• Start from a properly structured source document (real headings, lists and table headers) and export with tags instead of scanning paper.
• Add alternative text to meaningful images and mark decorative ones as such.
• Set the document language and a descriptive title.
• Make sure the reading order is correct, and run the accessibility checker built into your editor, then check by hand.
• Caption videos, and describe important visual information for people who cannot see it.

Common vendor mistakes

• Handing over a conformance report that says "Supports" for every row with no explanation.
• Testing only the home page.
• Describing the product by its last release, not the current one.
• Relying on an automated scan and skipping assistive technology.
• Having no named contact for accessibility questions.

A preparation timeline for a vendor

508 and the ADA together

They are separate laws with separate scopes, and they overlap in practice. Building to WCAG 2.2 AA, testing by hand and documenting the work answers most of what a federal agency, a state agency, a university or a large private buyer will ask.

Functional performance criteria in plain language

Alongside the technical requirements, the standards list functional performance criteria. They describe outcomes that a product should support, and they are useful for buyers because they apply to things the technical rules do not cover neatly.

What a sample test report looks like

Buyers like reports they can skim and trust. A good test report for a web product is short and specific.

• Header. Product name, version, test date, tester name or team, standard and version.
• Scope. The pages, screens and tasks tested, and the browsers, devices and assistive technology used.
• Summary. How many criteria were evaluated, how many are met, partly met or not met.
• Details. For each unmet criterion, an example, why it is a problem and a plan or date to fix it.
• Contact. A named person or address for accessibility questions.

Questions agencies commonly ask vendors

1. Which version of the product does the report describe, and is that the version we are buying?
2. Who performed the evaluation and how?
3. Which user tasks were tested end to end?
4. What is your process for fixing reported accessibility problems, and how fast do you respond?
5. How do you check new releases before they ship?

If you are the vendor, prepare answers to these before the first meeting. A short, honest answer builds more trust than a long polished one.

Pairing automated checks with hands-on testing

Automated tools are quick and consistent, and they are an excellent first pass. They can detect many missing labels, contrast failures and invalid markup. They cannot judge whether alternative text is accurate, whether the reading order makes sense, or whether a custom control is usable with a screen reader. Federal testing methods therefore combine automated checks with manual steps. See what scanners cover.

Common Section 508 web failures

• Images and icons without text alternatives (alt text guide).
• Forms where fields lack labels or errors are not explained (form labels).
• Menus, dialogs and widgets that cannot be used with a keyboard, or where focus is invisible (keyboard focus).
• Low-contrast text and controls (contrast guide).
• PDFs and office documents that are not tagged or structured, which agencies often check separately from web pages.
• Video without captions, and audio without a transcript.

A worked example: a vendor with a web application

Imagine a small company that sells scheduling software to school districts and now wants a state agency as a customer. The agency asks for an accessibility conformance report. The company's first step is to choose which version of the product to describe, since the report must match what the agency will actually use.

Next, the team lists the tasks a customer performs: signing in, creating a schedule, editing a shift, exporting a report and changing account settings. They test each task with only a keyboard, then with a screen reader, then at 200 percent zoom, and run an automated scan on each screen. The keyboard pass finds that the calendar cannot be reached without a mouse, and the screen reader pass finds that the export button has no name.

They fix both, record the other gaps honestly in the report as "partially supports" with a short explanation, and give the agency a contact address and a date by which the remaining items will be fixed. The report takes about three weeks of part-time effort. The agency does not expect a perfect product; it expects an honest one with a plan.

A note on WCAG 2.0 versus later versions

Because Section 508 points to WCAG 2.0, a vendor can meet it and still miss newer criteria such as reflow and text spacing from WCAG 2.1. Many agencies and large buyers now ask vendors to test against 2.1 or 2.2 AA as well, so building to 2.2 AA covers both. See WCAG levels and versions.

Clir's report shows which findings relate to criteria included in Section 508's WCAG 2.0 baseline. That is informational context for a technical finding and does not establish that a product meets Section 508.