Skip to main content

Section 508 Compliance: The Complete Guide

How Section 508 of the Rehabilitation Act came to govern federal technology, what the Revised 508 Standards actually require, who has to comply, and the practical steps for testing, documenting, and remediating your website or product.

Disclaimer: This guide is provided for informational purposes only and does not constitute legal advice. Accessibility requirements vary by jurisdiction and circumstance. Consult a qualified attorney for guidance specific to your organization.

What Is Section 508?

Section 508 is a provision of the Rehabilitation Act, the 1973 federal law that prohibits disability discrimination in programs run or funded by the federal government. Section 508 itself was added to the Act in 1986, but the version that matters today comes from the Workforce Investment Act of 1998, which rewrote it into an enforceable mandate: federal agencies must ensure that the electronic and information technology they develop, procure, maintain, or use is accessible to people with disabilities, both federal employees and members of the public.

The 1998 amendment directed the U.S. Access Board, an independent federal agency, to publish technical standards defining what “accessible” means. The Access Board issued its original standards in December 2000, and enforcement began in 2001. Those original standards were written for the technology of their era and grew increasingly out of step with the web, which is why the Access Board eventually replaced them.

Two things distinguish Section 508 from most accessibility laws. First, it is a procurement law as much as a civil rights law: accessibility is baked into how the federal government buys technology, which gives it enormous indirect reach over the private vendors that sell to it. Second, it comes with a concrete technical standard, so “compliant” has a testable definition rather than being argued case by case.

This guide goes deep on the law, the standards, and the process. If you want a shorter, conversational introduction first, start with our blog post Section 508 Compliance Explained and come back here for the detail.

The Revised 508 Standards and WCAG 2.0 AA

In January 2017, the Access Board published the Revised 508 Standards, often called the “508 Refresh,” with a compliance date of January 18, 2018. The refresh modernized the standards in three important ways.

WCAG 2.0 Level AA, incorporated by reference

Rather than maintaining a separate federal checklist, the Revised Standards adopt the WCAG 2.0 Level A and Level AA success criteria as their technical requirement for web content. They also apply those same criteria to non-web electronic documents and software, extending WCAG beyond its original scope. This is the single most practical fact about modern 508 compliance: for websites, testing against WCAG is testing against Section 508.

From product categories to functionality

The original standards were organized by product type (computers, telecommunications products, video equipment). The Revised Standards are organized around features and functionality, which keeps them relevant as devices converge. A smartphone is simultaneously a computer, a phone, and a media player; the revised approach handles that gracefully.

Alignment with international standards

By adopting WCAG, the refresh harmonized U.S. federal requirements with the standard used across most of the world, including the European EN 301 549 standard. Vendors can build to one technical bar and document conformance once.

Note the version detail: Section 508 formally requires WCAG 2.0 AA, while the newer WCAG 2.1 and 2.2 add criteria on top of it. WCAG 2.2 includes every WCAG 2.0 AA criterion still in force plus the additions from 2.1 and 2.2 (2.2 retired the obsolete parsing criterion 4.1.1), so a site that meets WCAG 2.2 AA covers the 2.0 AA baseline in practice. Testing against the current version, as CompliaScan does, covers the 508 requirement and positions you for other laws that reference newer versions.

What Counts as ICT?

The Revised Standards use the term information and communication technology (ICT), and it is deliberately broad. If a federal agency develops it, buys it, maintains it, or uses it, and it stores or transmits information, it is likely in scope.

Websites and web applications

Public-facing agency sites and internal tools alike must meet WCAG 2.0 Level AA. This is the largest and most visible category, and the one automated scanning addresses directly.

Software

Desktop applications, mobile apps, and operating system components. Software must meet the WCAG criteria (applied to non-web software) plus interoperability requirements for assistive technology.

Electronic documents

PDFs, Word documents, spreadsheets, and presentations that agencies publish or distribute. Untagged PDFs are one of the most common 508 failures in practice.

Hardware

Kiosks, multifunction printers, information transaction machines, and telecommunications equipment, with requirements for physical operability, displays, and audio output.

Who Must Comply?

Section 508 formally binds federal agencies. In practice, its requirements reach three groups.

Federal agencies

Agencies are directly responsible for the conformance of the ICT they develop, procure, maintain, and use. Individuals with disabilities can file complaints through each agency's Section 508 complaint process, and the Act provides for civil actions against agencies. Agencies also self-report their compliance posture to the government, which keeps internal pressure on 508 programs.

Vendors and contractors selling ICT to the government

Section 508 does not regulate private companies directly, but agencies are required to buy accessible ICT, and that requirement flows into contracts through the Federal Acquisition Regulation. Solicitations routinely specify the applicable 508 requirements and ask offerors to document conformance in an Accessibility Conformance Report. For a vendor, 508 conformance is a market-access requirement: an inaccessible product can be excluded from federal opportunities regardless of its other merits.

State agencies under 508-equivalent state laws

Many states have adopted accessibility requirements for state government IT that mirror or reference Section 508, sometimes called “little 508” laws. A driver for this was the federal Assistive Technology Act, which conditioned funding on states committing to 508-style compliance. The result: if you sell technology to state agencies, you will often face 508-equivalent requirements even though the federal law does not apply directly.

Spotlight: Maryland's nonvisual access requirements

Maryland is a clear example of state-level adoption. Maryland law requires that information technology procured or used by state agencies support nonvisual access, meaning it must be usable by people who are blind or have low vision, and the state's IT accessibility policy aligns with current WCAG standards. Vendors bidding on Maryland state IT contracts are expected to meet these requirements, and nonvisual access clauses appear in state procurement. If Maryland agencies are part of your market, review our Maryland accessibility requirements page alongside this guide.

Procurement and the VPAT Process

Because Section 508 operates through purchasing, its paperwork revolves around one document: the Accessibility Conformance Report (ACR), almost universally called a VPAT after the Voluntary Product Accessibility Template it is built on. The template is published by the Information Technology Industry Council (ITI) and comes in editions covering Section 508, WCAG, and the European EN 301 549 standard.

A VPAT walks through each applicable criterion and asks the vendor to declare a conformance level: supports, partially supports, does not support, or not applicable, with remarks explaining each answer. Federal buyers use these reports to compare products during market research and evaluation, and a missing or obviously careless VPAT is a red flag that can cost you the deal.

Three things make a VPAT/ACR credible. First, it is based on actual testing, automated plus manual, rather than aspiration. Second, it is honest about gaps: “partially supports” with a clear remark and a remediation plan reads far better to an experienced buyer than a suspicious wall of “supports.” Third, it is current: buyers discount reports that predate the product version they are evaluating. A VPAT is a disclosure document, not a certification, and nobody certifies you as “508 compliant.” The report simply documents what you tested and what you found.

Start your VPAT from real scan data

Our free VPAT starter generator turns a CompliaScan scan into a draft starting point, with the machine-testable criteria pre-populated from your results. You still need manual testing to complete the report, but you skip the blank-page stage. To see what a finished scan-derived report looks like, browse our own live ACR, generated from a real scan of this site.

How to Test for Section 508 Conformance

Since the technical standard is WCAG, testing for 508 is testing for WCAG. A credible testing program combines automated scanning with manual review; neither is sufficient alone.

  1. 1

    Run automated scans across your pages

    Automated tools reliably detect the machine-testable subset of WCAG criteria, roughly 30 to 40 percent: missing alt text, insufficient color contrast, missing form labels, incorrect ARIA usage, empty links, and undeclared page language. Scan every page template, not just the homepage, because issues concentrate in shared components and repeat across the site.

  2. 2

    Do a keyboard-only pass

    Unplug the mouse and complete your core user journeys with Tab, Shift+Tab, Enter, Space, and the arrow keys. Every interactive element must be reachable and operable, focus must be visible at all times, and nothing should trap the keyboard. This single exercise surfaces a large share of the issues automation cannot see.

  3. 3

    Test with a screen reader

    Use NVDA or JAWS on Windows, or VoiceOver on macOS and iOS, to walk through the same journeys. Listen for meaningful reading order, sensible announcements for dynamic content like modals and validation errors, and link text that makes sense out of context. Federal 508 testing programs, such as the DHS Trusted Tester process, lean heavily on this kind of structured manual evaluation.

  4. 4

    Check documents and media

    Remember that 508 covers electronic documents and multimedia, not just web pages. PDFs need tags, a logical reading order, and document titles. Videos need captions, and prerecorded video generally needs audio description. These are frequent findings in agency audits and procurement reviews.

  5. 5

    Monitor continuously

    Every deploy can introduce regressions. Scheduled automated scans catch machine-testable issues as they appear and create an audit trail showing ongoing diligence, which matters both for agency 508 programs and for vendors keeping a VPAT/ACR current.

Prioritizing Remediation

Most audits produce more findings than a team can fix at once. Prioritize by user impact and reach rather than working down the list in order.

  • 1. Blockers on core tasks

    Fix anything that prevents a user from completing a primary journey first: forms that cannot be submitted by keyboard, unlabeled required fields, focus traps in modals, and inaccessible authentication. A blocker on one critical path outweighs dozens of cosmetic issues.

  • 2. Issues in shared components

    A contrast failure in your navigation or a missing label in a shared form control repeats on every page. Fixing shared templates and components collapses hundreds of findings into a handful of changes, which is the fastest way to move an overall score.

  • 3. High-traffic pages and documents

    Weight fixes by how many people encounter them. The homepage, search, top landing pages, and your most-downloaded PDFs come before rarely visited archive content.

  • 4. Everything else, tracked and scheduled

    Lower-severity findings still matter for conformance. Track them in your backlog with owners and dates, and reflect the honest current state in your VPAT remarks. Documented, in-progress remediation is a defensible posture; an undocumented pile of known issues is not.

See Where Your Site Stands Against the 508 Baseline

Run a free scan against WCAG 2.2 Level AA, a superset of the WCAG 2.0 AA standard the Revised 508 Standards require. You get a score, a severity breakdown, and fix suggestions in seconds. Automated scanning covers the machine-testable subset; pair it with the manual steps above for full coverage. Prefer the full picture first? Visit the Section 508 compliance checker page.

Related Resources