Section 508 compliance: what federal websites and technology must meet

This page explains the federal rule and links each point to its official text: the statute at 29 U.S.C. 794d, the Revised 508 Standards in 36 CFR Part 1194, and the government's own Section508.gov. For the wider US picture, see US web accessibility laws.

Section 508 at a glance

Who Section 508 covers

Section 508 is part of the Rehabilitation Act of 1973. The statute puts the duty on the government itself: "When developing, procuring, maintaining, or using electronic and information technology, each Federal department or agency, including the United States Postal Service, shall ensure, unless an undue burden would be imposed" that the technology is accessible (29 U.S.C. 794d). Section508.gov puts the goal plainly: agencies "must give disabled employees and members of the public access to information comparable to the access available to others" (Section508.gov).

The standards define an agency as "Any agency or department of the United States as defined in 44 U.S.C. 3502, and the United States Postal Service", and set the scope in one line: "ICT that is procured, developed, maintained, or used by agencies shall conform to the Revised 508 Standards" (36 CFR 1194, Appendix A, E103.4 and E201.1, published by the U.S. Access Board). ICT is broad. The definition's examples include computers, information kiosks, software, applications, "Web sites; videos; and, electronic documents".

Contractors and vendors

Section 508 does not, by its own terms, place a duty on private companies. It reaches them through procurement. Section508.gov tells sellers that "Government solicitations which include ICT will specify accessibility requirements, indicating which provisions are required to ensure the deliverable is accessible" (Section508.gov, ACR). A company that builds a website, an app or a document set for an agency is held to the Revised 508 Standards through the agency's contract. Section508.gov lists FAR 39.2, in the Federal Acquisition Regulation, as the "Primary accessibility acquisition requirements to ensure federal employees and members of the public have equal access to information" (Section508.gov).

The standards also carve out one contractor case: "ICT acquired by a contractor incidental to a contract shall not be required to conform to the Revised 508 Standards" (Appendix A, E202.4). What the agency receives, uses or puts in front of the public is in scope; the exception does not cover it.

Who it does not cover

Organizations that receive federal funding are not covered by Section 508 by virtue of that funding. They fall under Section 504 of the same Act, which applies to "any program or activity receiving Federal financial assistance" (29 U.S.C. 794); the HHS web rule described below is one example.

State and local governments are not covered by Section 508. Their websites fall under the ADA Title II web rule, which uses WCAG 2.1 Level AA; see our page on Title II website accessibility for local governments. Businesses open to the public fall under ADA Title III, which has no web regulation; see ADA website compliance for businesses. Some states also have their own technology accessibility laws for state agencies, and Section508.gov keeps a list of state accessibility laws and policies.

The 2017 refresh: WCAG 2.0 Level A and AA

On January 18, 2017 the U.S. Access Board issued a final rule that "updated accessibility requirements covered by Section 508" (Section508.gov; the text is on the U.S. Access Board site). Section508.gov records that "The final rule went into effect on January 18, 2018", and that the refresh harmonized the requirements with standards in the US and abroad and "with the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG 2.0)".

The core requirement is one sentence in the standards: "Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0" (Appendix A, E205.4). The same WCAG 2.0 A and AA requirement applies to software user interfaces (E207.2) and to support documentation in electronic form, "including Web-based self-service support" (Appendix C, 602.3). The version incorporated is the W3C Recommendation of December 11, 2008 (Appendix C, 702.10.1).

By our count from the WCAG 2.0 specification, Level A and AA together make 38 success criteria (25 at A, 13 at AA). The full list, with plain-language summaries, is on our WCAG criteria page.

Documents and software that are not web pages

WCAG was written for web pages, so the standards adapt it. For a non-web document, the word "document" is substituted wherever WCAG says "Web page" or "page" (Appendix A, E205.4.1), and the same substitution with "software" applies to non-web software (E207.2.1). Non-web documents also do not have to meet four criteria that only make sense across a set of pages: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification (E205.4, Exception).

That makes PDFs, Word files and spreadsheets part of Section 508 work. Our PDF accessibility checker runs a structural first pass on a PDF in your browser (tags, language, title, headings, figure alt text and more), and our guide to accessible PDFs covers the fixes.

WCAG 2.0 is older than the current version

WCAG 2.2 is the current W3C Recommendation, and W3C states that "Content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1" (WCAG 2.2). WCAG 2.2 removed 4.1.1 Parsing as obsolete, and W3C notes that authors held to 2.0 or 2.1 "may need to continue to test and report 4.1.1". Section 508 incorporates the 2008 text, so 4.1.1 is still a 508 requirement, but the federal Section 508 ICT Testing Baseline adopts W3C's WCAG 2.0 errata: "This criterion should be considered as always satisfied for any content using HTML or XML." Problems a duplicate id causes for users are reported under other success criteria.

The reverse also holds: criteria added in WCAG 2.1 and 2.2 are not part of Section 508's requirements. 1.4.11 Non-text Contrast, for example, was added in WCAG 2.1. Building to WCAG 2.2 AA meets the WCAG part of Section 508 and goes further, though the standards also have requirements outside WCAG, such as Chapter 5 for software and 602 for support documentation. See which WCAG version the law requires and what is new in WCAG 2.2.

Which content has to conform

All public facing electronic content must meet WCAG 2.0 A and AA (Appendix A, E205.2). The standards define it as "Content made available by an agency to members of the general public. Examples include, but are not limited to, an agency Web site, blog post, or social media pages."

Content that is not public facing must conform when it is official agency business communicated as one of nine kinds of content (Appendix A, E205.3):

• an emergency notification;
• an initial or final decision adjudicating an administrative claim or proceeding;
• an internal or external program or policy announcement;
• a notice of benefits, program eligibility, employment opportunity or personnel action;
• a formal acknowledgment of receipt;
• a survey questionnaire;
• a template or form;
• educational or training materials;
• intranet content designed as a web page.

Records that the National Archives and Records Administration keeps under federal recordkeeping law are excepted unless they are public facing.

Requirements beyond WCAG

WCAG 2.0 is the largest part of the Revised 508 Standards, but not all of it. The scoping rules are in Appendix A and the technical chapters in Appendix C, and these parts go beyond WCAG:

• Functional performance criteria (Chapter 3). "Where the requirements in Chapters 4 and 5 do not address one or more functions of ICT, the functions not addressed shall conform to the Functional Performance Criteria specified in Chapter 3" (E204.1). The criteria describe outcomes, such as at least one mode of operation "that does not require user vision" (302.1).
• Hardware (Chapter 4). Hardware that transmits information or has a user interface must meet Chapter 4 (E206.1).
• Software (Chapter 5). Software must meet Chapter 5 as well as WCAG (E207.1). "Software shall interoperate with assistive technology" (502.1), and applications "shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor" (503.2), with an exception for applications designed to be isolated from their underlying platform, including web applications.
• Authoring tools (504). Software used to create or modify content for others "shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0" (504.2).
• Support documentation and services (Chapter 6). Documentation "shall list and explain how to use the accessibility and compatibility features required by Chapters 4 and 5" (602.2). Support services, "including, but not limited to, help desks, call centers, training services, and automated self-service technical support", must meet 603 (603.1), which includes accommodating "the communication needs of individuals with disabilities" (603.3).

A website scan or a WCAG audit speaks only to the WCAG part. Software vendors and agencies buying software need to cover the other chapters as well.

Exceptions in the standards

Appendix A, E202, lists the general exceptions. Each is narrow, and the two that rest on an agency's own judgment have to be written down.

Where a VPAT and an ACR fit in procurement

Section508.gov describes an Accessibility Conformance Report (ACR) as "a document that explains how information and communication technology (ICT) products such as software, hardware, electronic content, and support documentation meet (conform to) the Revised 508 Standards". It adds that ACRs "help Federal agency contracting officials and government buyers to assess ICT for accessibility when doing market research and evaluating proposals", and recommends "that vendors generate an ACR for any ICT that's intended to be marketed to the Federal government" (Section508.gov, ACR).

Section508.gov's own instructions are titled "How to Create an ACR with a VPAT®", meaning the Voluntary Product Accessibility Template from the Information Technology Industry Council (ITI). ITI calls it "a free template", lists the current release as "VPAT® Version 2.5Rev (April 2025)" in 508, EU, WCAG and INT (combined) editions, and explains that "Once completed, the VPAT® with documented testing results is referred to as an Accessibility Conformance Report (ACR)" (ITI).

Two points matter to both sides of a purchase. An ACR is the vendor's own account of its product, so its value depends on the testing behind it, and a buyer can test the parts that matter most to its users. And an ACR describes a product at a point in time; a site or app that changes every week can drift from what its report says. Our guide to VPATs and ACRs walks through how to write and read one.

Section 508 and the ADA: how they differ

The two laws are often mentioned together, but they cover different organizations and name different WCAG versions.

On enforcement, the statute lets "any individual with a disability" file a complaint alleging that an agency "fails to comply with subsection (a)(1) in providing electronic and information technology", and makes the remedies, procedures and rights of the Rehabilitation Act's section 794a available to that person (29 U.S.C. 794d(f)). Subsection (f)(1)(B) limits that complaint route to technology "procured by a Federal department or agency".

A fourth rule sits alongside these: organizations that receive HHS funding, such as hospitals, have a Section 504 web rule that also uses WCAG 2.1 AA, with dates of May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for those with fewer (91 FR 25496). Section508.gov also lists the related policies agencies work under, including the 21st Century Integrated Digital Experience Act and OMB memorandum M-24-08, "Strengthening Digital Accessibility and the Management of Section 508 of the Rehabilitation Act" (Section508.gov). Section508.gov says M-24-08 "requires federal agencies to maintain an accessibility statement on their websites", and its guide to developing a website accessibility statement gives information and examples. Our statement generator gives a structured first draft.

The rule of thumb for a team that serves more than one of these audiences: build to WCAG 2.2 Level AA. That meets or goes beyond the WCAG level each rule above names; Section 508 also has requirements outside WCAG for software, hardware and support documentation, and Title III names no technical standard.

How to check content against Section 508

1. List what is in scope

   Start with public facing content: the site, its PDFs and other documents, video, and social media pages. Then add internal content that falls in the nine categories above, such as forms, training materials and intranet pages.

2. Run the machine checks first

   A free scan runs 16 rule checks on up to three pages, each mapped to a WCAG criterion. The accessibility bookmarklet checks any page in your browser, including pages behind a login. For focused checks, use the contrast checker, heading checker and link text checker.

3. Check what machines cannot

   Automated checks find only part of what WCAG asks. Try every page with a keyboard alone (our keyboard accessibility test takes five minutes), listen to key pages with a screen reader, and check that images are described correctly, not just described. Our testing guide covers the full sequence. For federal work, the ICT Testing Baseline Portfolio "establishes the minimum requirements for evaluating the conformance of ICT" with Section 508, with separate baselines for web content and electronic documents; it is the federal reference for what a 508 test process has to cover.

4. Record what you tested

   Keep a dated record of what was tested, how and what was fixed. For a vendor, that record is the raw material of an accurate ACR. For an agency, it supports the written determinations the exceptions require.