Section 508 compliance, explained: what the Revised 508 Standards require and what a vendor hands over

"Section 508 compliance" is searched about 5,400 times a month in the United States, and most of what comes back is a vendor's landing page that says the words and moves on to a demo form. This is the long version: what the law says, what the rule says clause by clause, which parts reach a company that sells to the government, the details that trip up even careful vendors, and a checklist for the report a federal buyer will ask you for. Every clause number below is from the rule text at 36 CFR Part 1194, and every figure is from the agency that published it.

The law, the rule and the contract: three layers

People say "Section 508" for three different things, and most confusion comes from mixing them up.

The statute says nothing about you. It obliges agencies. The standards say what accessible means in technical terms. You meet Section 508 because the Federal Acquisition Regulation tells the agency to buy only what meets the standards. FAR 39.203(a) says acquisitions "for ICT supplies and services shall meet the applicable ICT accessibility standards at 36 CFR 1194.1", and 39.203(b) says the contract must identify which supplies and services the contractor says meet them. That second sentence is where your Accessibility Conformance Report comes in: it is how you tell the agency what to write into the contract.

This matters in practice. A vendor who reads "Section 508 compliance" as a badge to earn is solving the wrong problem. The agency is not asking for a yes or a no. It is asking which of the standard's requirements your product meets, so it can document its own decision.

What the Revised 508 Standards actually contain

The Access Board published the Revised 508 Standards in the Federal Register on January 18, 2017, and agencies had to follow them from January 18, 2018. They replaced the original 2000 standards, which had their own web rules written before WCAG existed. The rule is in three appendices: Appendix A is the 508 scoping (Chapters 1 and 2, the "E" provisions), Appendix B is the parallel Section 255 telecom scoping, and Appendix C is the technical requirements both share (Chapters 3 to 7).

The scoping chapter decides what applies. The technical chapters say how.

Electronic content means more than websites

E205.4 says electronic content "shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0". That covers a public website, and it also covers a PDF, a Word file, a slide deck and a spreadsheet. For documents, E205.4.1 tells you to read "document" wherever WCAG says "Web page". Four criteria that only make sense across a set of pages do not apply to a single document: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification.

Not everything an agency writes is covered. Public-facing content always is (E205.2). Internal content is covered when it is official business in one of nine categories listed at E205.3: emergency notifications, decisions on administrative claims, program or policy announcements, notices of benefits, eligibility, employment or personnel actions, formal acknowledgements of receipt, surveys, templates and forms, educational and training materials, and intranet content designed as a web page. If you sell an internal tool that produces any of those, its output is in scope even though nobody outside the agency will see it.

Software is held to WCAG too

This is the clause vendors of desktop and mobile software most often miss. E207.2 says "user interface components, as well as the content of platforms and applications, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0." A native Windows application, an iOS app and a web application are all measured against the same success criteria as a website. For non-web software, E207.2.1 substitutes "software" for "Web page", and the same four page-set criteria are excepted, along with WCAG's third conformance requirement on complete processes (E207.3 restates that requirement in software terms instead).

How do you apply a criterion written for web pages to a desktop dialog? The W3C publishes a guide for exactly that, WCAG2ICT. Its current version, a Group Note dated December 11, 2025, covers WCAG 2.0, 2.1 and 2.2 and works through every criterion for non-web documents and software. When a reviewer asks how you interpreted 2.4.3 Focus Order for a native application, WCAG2ICT is the answer they will accept.

On top of WCAG, Chapter 5 adds requirements that exist nowhere in WCAG:

• 502 Interoperability with assistive technology. Software must expose its controls to the platform's accessibility services (names, roles, states, values, text, focus), so screen readers and switch software can work with it. A web application that meets WCAG 2.0 AA and has no access to platform accessibility services is excepted from 502 and 503 altogether (501.1).
• 503 Applications. Applications permit the user's platform preferences for color, contrast, font type, font size and focus cursor (503.2); and where software plays synchronized video, the controls for captions and audio description sit at the same menu level as the volume or program controls (503.4).
• 504 Authoring tools. If your product lets people create content, as a CMS, an email builder, a form builder, a course authoring tool or a document editor does, it must let them create accessible content, and where it exports full-featured PDF it must support PDF/UA-1 (504.2.2). This is the most overlooked chapter in SaaS: the product can meet WCAG itself and still fail 504 because the content its users make cannot.

The functional performance criteria

Chapter 3 is nine plain statements: the product must offer at least one mode of operation usable without vision, with limited vision, without perception of color, without hearing, with limited hearing, without speech, with limited manipulation, with limited reach and strength, and with limited language, cognitive and learning abilities. They are not a second checklist to tick for every product. E204.1 applies them "where the requirements in Chapters 4 and 5 do not address one or more functions of ICT". In a report, they are where you say how the product works for each group when the technical requirements run out, and a reviewer reads them as a summary of everything above.

Support documentation and services

Chapter 6 is short and frequently left blank in vendor reports, which reviewers notice. Support documentation must list the product's accessibility and compatibility features and explain how to use them (602.2). Electronic documentation must itself meet WCAG 2.0 (602.3), which puts your help center and your PDF manual in scope. Support services, your help desk and training, must offer information on those features (603.2) and have a contact method that accommodates the communication needs of people with disabilities (603.3). A help desk reachable only by phone does not meet 603.3.

WCAG 2.0, in 2026

The Revised 508 Standards incorporate WCAG 2.0 by reference at 702.10.1, the W3C Recommendation of December 11, 2008. The W3C has since published WCAG 2.1 (2018) and 2.2 (2023), and other rules have moved on: the Department of Justice's ADA Title II web rule uses WCAG 2.1 Level AA, and EN 301 549, the European standard, uses 2.1. The 508 Standards have not been amended, and we could find no proposed rule to update them in the Federal Register as of October 2026.

Three practical consequences follow.

Test to WCAG 2.2, report against 2.0. WCAG versions are built to be backwards compatible: 2.1 added 17 criteria to 2.0, and 2.2 added nine more. A product that meets 2.2 Level AA meets the 38 Level A and AA criteria of 2.0. Testing to the newest version costs little more, and the same assessment then serves a federal buyer, a state university under Title II and an EU customer. The 508 edition of the VPAT asks only about the 2.0 rows; the WCAG and INT editions ask about all three versions.

4.1.1 Parsing is the exception. WCAG 2.2 removed Success Criterion 4.1.1 as obsolete. WCAG 2.0, which the 508 Standards still reference, kept it. In 2023 the W3C published errata for 2.0 and 2.1 explaining that the HTML standard now dictates how browsers handle broken markup, so "this criterion no longer provides any benefit to people with disabilities in itself", and WCAG 2.1 now carries a note that it "should be considered as always satisfied for any content using HTML or XML". The errata add that issues such as duplicate IDs that break a label are to be reported under the criteria they actually affect, usually 1.3.1 and 4.1.2. Many vendor reports still mark 4.1.1 as Partially Supports because a validator found duplicate IDs. In the 508 edition the row is still there and still has to be answered; the accurate answer for HTML content cites the W3C's own note and moves the real defects to the rows they belong in.

The 2.0 criteria are not the hard ones. Most of what a modern site fails is in 2.0: contrast (1.4.3), labels (1.3.1, 3.3.2, 4.1.2), keyboard operation (2.1.1), focus order (2.4.3) and visible focus (2.4.7). Our own audits of well-built sites found 1,041 contrast failures on two of them, all against a 2.0 criterion (the write-up is here).

The exceptions belong to the agency, not to you

The rule lists general exceptions at E202, and vendor marketing sometimes cites them as if a vendor could use them. A vendor cannot.

Best meets is the one that shapes competition. When no product in a field meets every requirement, the agency picks the one that meets the most, and it decides by reading the ACRs side by side. That is why an honest report with specific remarks beats a vague one even when both products have gaps: the reviewer can see exactly how much of the standard each one meets. FAR 39.204(b) requires the agency to put its written exception decisions in the contract file, so a reviewer who picks your product under best meets is citing your report in a document an auditor will read.

What agencies themselves report

GSA publishes a governmentwide assessment of Section 508 each year from agencies' own answers. The FY 2025 assessment, drawn from 212 agencies, parent agencies and components, reports an average conformance score of 1.96 on a 5-point scale, says that "approximately half of all agencies reported that they do not routinely test ICT for accessibility conformance", and names testing and remediation as "the weakest area of Section 508 implementation". GSA treats FY 2025 as a new baseline because the questions changed. The year before, from 245 reporting entities, agencies tested 41% of their public web pages, down from 52%, and intranet conformance fell from 59% to 52%.

Read that from the vendor's side. Many of the people evaluating your product do not have the capacity to test it. Your Accessibility Conformance Report is often the only accessibility evidence in the file. An agency that cannot verify a claim will lean on how believable the report is: whether it states its method, whether its levels vary, whether its remarks are specific. A report that reads as tested is worth more there than anywhere else.

Section 508 next to the other rules

Buyers outside the federal government ask for "508" too, often meaning something else. Here is where each rule sits.

A state university asking for "a 508 VPAT" usually wants the 508 edition because its procurement template says so, even though Title II, not Section 508, is what binds it. Send what they asked for. If you also have a WCAG 2.2 assessment behind it, say so in the evaluation-methods section; the reviewer who knows the difference will notice.

Myths, briefly

"Section 508 certification." No agency certifies products. The DHS Trusted Tester program certifies people in a manual test method for web content; an agency that has adopted that method accepts results only from testers DHS has trained and examined. The certificate is the tester's, and DHS itself says it does not currently offer a comprehensive test process for software.

"We meet 508." The sentence tells a reviewer nothing. Meets which provisions, for which version, tested how and when? FAR 39.203(b) asks the contract to identify what the contractor says meets the standards; a one-line claim leaves that blank.

"508 is just for websites." E205 covers documents, E207 covers every kind of software, E206 covers hardware, E208 covers your help desk.

"We meet WCAG 2.2, so we don't need a 508 report." You may meet every technical requirement, and a federal buyer will still ask for the 508 edition, because Chapters 3, 5 and 6 ask questions the WCAG edition does not.

The checklist for the 508 edition of your ACR

The 508 edition of the VPAT 2.5Rev template has the WCAG 2.0 tables followed by Chapter 3 (functional performance criteria), Chapter 4 (hardware), Chapter 5 (software) and Chapter 6 (support documentation and services). Before you send yours:

• Product, version and date are on page one. A federal reviewer matches the report to the version in the bid.
• The evaluation method is stated. What was tested, with which tools and assistive technologies, by whom, on what date, and what was not tested.
• The WCAG 2.0 table is complete at Level A and AA. Every row has a level and a remark. Not Evaluated is permitted only at AAA.
• 4.1.1 is answered with the W3C's note for HTML content, and real markup defects are reported under 1.3.1 or 4.1.2.
• Documents are covered. If your product ships or generates PDFs, Word files or templates, say how they perform; E205.4 applies to them.
• Chapter 3 summarizes each of the nine user groups, consistent with the WCAG rows above it.
• Chapter 4 says Not Applicable for software-only products, with a remark saying why.
• Chapter 5 answers 502 to 504 honestly. For a web application that meets WCAG 2.0 AA without platform access, say so and cite the 501.1 exception for 502 and 503. If your product is an authoring tool, 504 is not Not Applicable.
• Chapter 6 describes your real documentation and support channels, including how a deaf or hard-of-hearing customer reaches support.
• No word of certification anywhere. The report is your declaration, signed by you, even if someone else prepared it.

If you want the template's own definitions of the five conformance levels, our explainer on what a VPAT is has them, and filling out a VPAT honestly is the method for doing the WCAG table yourself.

Getting the 508 edition done

There are three routes, the same as for any edition: write it yourself from your own testing, hire a consultancy, or order one. Ours is the ACR, Section 508 edition: up to 50 pages tested in a real browser against WCAG 2.2 Level A and AA, the 2.0 rows the 508 edition asks about completed with levels and remarks, Chapters 3 to 6 completed from that assessment and from two questions about your documentation and support, reviewed by an accessibility analyst and delivered in three business days for $1,199. The report states exactly what was and was not tested, including that manual assistive-technology testing is not part of the method. A complete 508 edition produced against the W3C's demonstration site is on our samples page, so you can see every chapter before you order.

Whichever route you choose, the test is the one the agency's reviewer applies: does this report say, specifically and truthfully, which requirements of 36 CFR 1194 this version of this product meets? If it does, it does its job in the contract file.