Section 508 Compliance Guide: Requirements, Testing, and VPAT Basics for 2026

Picture a software company that has just reached the final round of a federal contract bid. Everything looks good until the procurement team sends one more request: “Please provide your Accessibility Conformance Report for Section 508.” Nobody on the sales team knows what that is, and the deadline is two weeks away.

This happens more often than you would expect. Section 508 compliance is one of those requirements that stays invisible until a contract, an agency, or a customer brings it up. This guide explains what it is, who it applies to, what it actually requires, and how to prepare, so that the request does not turn into a scramble.

What Is Section 508?

Section 508 is part of the Rehabilitation Act of 1973. It requires US federal agencies to make their information and communication technology (ICT) accessible to people with disabilities, both employees and members of the public. “ICT” is a wide term. It covers websites, software, mobile apps, electronic documents, videos, hardware, and support services.

Congress strengthened the law in 1998, but the technical rules were showing their age by the 2010s. In January 2017, the US Access Board published a “refresh” of the standards, and agencies had to comply by January 2018. The refreshed rules pulled in WCAG, the international web accessibility standard, and replaced much of the older, more prescriptive language.

If you want the plain-language version of our service side, our Section 508 compliance page gives an overview.

Who Needs to Follow Section 508?

The law applies directly to federal agencies. Most private companies are not covered on their own, but that is only half the story.

Federal contractors and vendors. When an agency buys ICT, it has to consider accessibility in the purchase. That means anyone selling software, websites, SaaS platforms, training content, or devices to a federal buyer will be asked how accessible the product is. Winning the deal often depends on the answer.

State and local governments, universities, and other organizations. Many states have adopted Section 508 or WCAG-based rules of their own. Public universities and organizations that receive federal funding are often held to similar expectations, even where the law is worded differently.

Everyone else selling to those buyers. If your customers include any of the above, they may pass the requirement down to you in their own procurement forms.

A quick practical test: if a customer has ever asked you for a VPAT, Section 508 is already part of your business, whether or not you are a federal contractor.

What Does Section 508 Actually Require?

The refreshed standards are organized into chapters. For most software and web teams, these are the parts that matter.

Web and Electronic Content

Section 508 incorporates WCAG 2.0 Level A and Level AA for web pages and for non-web electronic content such as PDFs, Word files, PowerPoint decks, and spreadsheets. In practice, many agencies and buyers now ask for WCAG 2.1 or 2.2 AA as well, so building to the newer version keeps you covered either way.

WCAG rests on four principles: content has to be perceivable, operable, understandable, and robust. The four accessibility principles explained is a helpful primer if your team is new to them. You can also read more about the standard itself on our WCAG compliance page.

Software and Applications

Software has its own requirements. It has to work with assistive technology such as screen readers, expose the right information (names, roles, values, states) to those tools, respect the user’s system settings for contrast and text size, and be fully usable from the keyboard. Authoring tools have extra rules: they must let people create accessible content and should not strip accessibility features out.

Functional Performance Criteria

Section 508 also describes what a product has to enable, in plain terms: use without vision, with limited vision, without hearing, with limited manipulation, with limited reach, and so on. These act as a safety net for cases the technical rules do not cover neatly.

Hardware and Support Documentation

Physical products such as kiosks, printers, and phones come with hardware requirements. Help desks, training materials, and product documentation must also be accessible. This part is easy to forget, because teams usually focus on the product itself and overlook the PDF user guide.

Video and Multimedia

Prerecorded video needs captions and, where visuals carry information, audio description. Live video needs captions. If your product ships with onboarding videos or training clips, they count.

For a closer look at one common content type, see our guide to Section 508 compliance for eLearning.

Exceptions Exist, but Do Not Lean on Them

The standards allow a few exceptions, including national security systems, certain legacy content, and cases where compliance would create an undue burden or fundamentally change the product. Agencies have to document these decisions, and they are meant to be the exception, not the plan. If you are a vendor, assuming your product qualifies for one is a risky strategy. Build to the standard and treat the exceptions as a last resort.

VPAT and ACR: The Paperwork That Proves It

Two terms come up constantly in Section 508 conversations, and people often mix them up.

A VPAT (Voluntary Product Accessibility Template) is the blank form, created by the Information Technology Industry Council. An ACR (Accessibility Conformance Report) is the completed document that describes how your product meets each requirement. In everyday speech, most people say “VPAT” when they mean the finished report.

The ACR lists each criterion and states how well the product meets it: Supports, Partially Supports, Does Not Support, or Not Applicable, with remarks explaining why. There are separate VPAT editions for Section 508, WCAG, and the European standard EN 301 549, and many vendors publish a combined version.

A few points about ACRs are worth stating clearly:

• An ACR should be based on real testing, not on what you hope is true. Buyers do check.
• Honest “Partially Supports” answers with a remediation plan are better received than a suspiciously perfect report.
• The report goes stale. Every major release can change the results, so it needs regular updates.

Our VPAT preparation and review services help teams produce and check these documents, and what a certified WCAG compliance auditor does explains why an auditor’s credentials matter to the credibility of the report.

How to Test for Section 508 Compliance

Good testing combines tools and people.

Start With Automated Scanning

Automated tools find problems such as missing alternative text, low contrast, and unlabeled form fields quickly. They are a good first pass. Our D2i AccessScan tool is one option, and our Color Contrast Analyzer helps with checking color pairs. Automated scanners typically catch only a portion of real issues, often estimated at 30 to 40 percent, so they can never be the whole story.

Add Manual Testing With Assistive Technology

This is the step that most closely reflects a real user’s experience. Testers work through key user flows with a screen reader (NVDA or JAWS on Windows, VoiceOver on Apple devices), with the keyboard alone, and with zoom and high-contrast settings. They find the problems scanners cannot: confusing focus order, dialogs that trap the keyboard, error messages that are never announced.

Manual vs automated accessibility audits explains the split in more depth, and our keyboard navigation guide covers one of the most common failure areas. Our accessibility testing services combine both methods.

Test Documents and Media Too

Section 508 covers PDFs, office files, and video, so test those as well. A polished website can still fail an audit because the downloadable brochure is an untagged PDF.

A Simple Path to Section 508 Compliance

Here is a sequence that works for most teams.

1. Define your scope. List the products, pages, documents, and media in play. If the request came from a specific agency or contract, check what version and level it names.

2. Audit. Run a full evaluation against WCAG and the Section 508 criteria that apply to your product type. Our step-by-step guide to a product accessibility audit shows what a thorough one looks like.

3. Fix what you find. Prioritize issues that block users completely, then work down the list. Why accessibility remediation matters covers how to sequence the work, and our accessibility remediation team handles implementation and retesting.

4. Document. Complete an ACR based on the tested results. Keep the audit report and remediation record, since you may need them later.

5. Make it a habit. Add accessibility checks to your development process so each release does not undo the last one. Our accessibility compliance audit checklist is a useful reference for setting up recurring reviews.

If you buy software rather than sell it, our accessibility strategy for procurement covers how to ask vendors the right questions.

Mistakes We See Often

Treating the VPAT as a marketing document. A report written without testing tends to fall apart the first time a buyer’s own evaluator checks it.

Testing only the main website. The login portal, the admin dashboard, the mobile app, the PDFs, and the help center all count.

Relying on an overlay. Widgets that promise instant compliance do not fix the underlying code and do not replace testing with real assistive technology.

Fixing once and forgetting. New features and third-party integrations bring new issues. Compliance is something you maintain.

How D2i Technology Can Help

D2i Technology supports organizations through the whole Section 508 process: audit, manual and automated testing, remediation, retesting, and VPAT or ACR preparation. Our team includes IAAP-certified professionals (CPACC, WAS, and CPWA), and we work with clients across the US and India. Because the same WCAG foundation supports the ADA and the European Accessibility Act, work done for Section 508 usually helps with those too. Our accessibility compliance page and our guide to ADA Title II requirements show how the frameworks connect.