Section 508: Accessibility Requirements for Selling ICT to US Agencies
Section 508 requires US federal agencies to make the information and communication technology they develop, buy, maintain or use accessible to people with disabilities. The Revised 508 Standards, in force since January 2018, incorporate WCAG 2.0 Level A and AA for web content, documents and software, and add requirements for hardware, support documentation and services. Vendors selling to agencies are asked for an Accessibility Conformance Report, usually based on the VPAT template, and may face accessibility testing.

Section 508 of the Rehabilitation Act requires US federal agencies to make the information and communication technology (ICT) they develop, procure, maintain or use accessible to people with disabilities. That covers websites, web applications, software, documents, mobile apps, hardware and support services. Because agencies must buy accessible products, the law shapes what vendors must deliver and document.
The Revised 508 Standards, published by the US Access Board in January 2017 and in force since January 2018, incorporate the Web Content Accessibility Guidelines (WCAG) 2.0 at Level A and AA. Vendors are usually asked for an Accessibility Conformance Report based on the VPAT template. This guide explains who must comply, what the standards require, how ACRs work, how to test, and how Section 508 relates to WCAG 2.2, the ADA and the European Accessibility Act.
What is Section 508?
Section 508 was added to the Rehabilitation Act in 1986 and strengthened in 1998 to require federal agencies to ensure their electronic and information technology is accessible, unless doing so would impose an undue burden. Federal employees with disabilities must have access comparable to others, and members of the public with disabilities seeking information or services from an agency must have comparable access.
The US Access Board publishes the technical standards. The original 2000 standards were replaced by the Revised 508 Standards, which harmonise with WCAG and with the European standard EN 301 549. The General Services Administration supports agencies through Section508.gov, including guidance on testing and procurement.
Who must comply?
- Federal agencies, for all ICT they develop, procure, maintain or use.
- Vendors and contractors, indirectly, because agencies must buy conforming products and include accessibility requirements in contracts.
- States, universities and others that adopt Section 508 standards in their own laws or policies, often for procurement.
Private companies that do not sell to federal agencies are not covered by Section 508 itself, though the ADA and state laws may still require accessibility. Federally funded programmes, such as some grants and educational services, may also carry accessibility requirements through other laws, so organisations receiving federal money should check their obligations carefully.
Is it mandatory or voluntary?
Mandatory for federal agencies. For vendors, it becomes a contractual requirement and an evaluation factor. Agencies may accept products that do not fully conform when no conforming product exists or when an exception applies, but they must document the decision and provide alternative access.
What the Revised 508 Standards require
| Chapter | Coverage |
|---|---|
| Application and scoping | Which ICT is covered, exceptions, and how standards apply to electronic content, including documents and communications. |
| Functional performance criteria | Outcomes for users without vision, with limited vision, without colour perception, without hearing, with limited hearing, without speech, with limited manipulation, reach or strength, and with limited language, cognitive and learning abilities. |
| Hardware | Requirements for physical products such as kiosks, printers and phones. |
| Software | Requirements for desktop, mobile and web applications, including interoperability with assistive technology and authoring tools. |
| Support documentation and services | Accessible documentation and help desk services. |
| WCAG 2.0 incorporation | Web content, non-web documents and software must conform to WCAG 2.0 Level A and AA success criteria, applied as the standards specify. |
Applying WCAG to documents and non-web software is a key feature: PDFs, Word files, spreadsheets and desktop applications must meet the same criteria where applicable.
Exceptions and safe harbour
The standards include limited exceptions. Existing ICT that conformed to the original 2000 standards does not need upgrading solely because of the 2017 refresh, unless it is altered, in which case altered elements must meet the new standards. Agencies may claim undue burden or fundamental alteration when conformance would impose significant difficulty or expense or fundamentally change the product, but they must document the claim and provide an alternative means of access. Some national security systems and ICT functionally located in maintenance spaces are excepted. When no product fully conforms, agencies must procure the product that best meets the standards consistent with business needs, which is why honest ACRs matter in competitive evaluations.
Section 508 and newer WCAG versions
The standards reference WCAG 2.0, published in 2008. WCAG 2.1 (2018) and WCAG 2.2 (2023) add success criteria for mobile use, low vision and cognitive disabilities. Conforming to WCAG 2.1 or 2.2 Level AA also satisfies the WCAG 2.0 criteria, so many vendors target WCAG 2.2 AA to meet Section 508, the ADA Title II rule, which uses WCAG 2.1 AA, and the European Accessibility Act together. The Access Board has discussed updating the standards, but as of October 2026 the 2017 standards based on WCAG 2.0 remain in force.
Accessibility Conformance Reports and VPATs
An Accessibility Conformance Report (ACR) documents how a product conforms to accessibility standards. Most vendors create ACRs using the Voluntary Product Accessibility Template (VPAT) published by the Information Technology Industry Council, which has editions for Section 508, WCAG, EN 301 549 and an international edition covering all three. For each criterion, the report states whether the product supports, partially supports or does not support it, or whether the criterion is not applicable, with remarks explaining details.
Agencies use ACRs in market research and evaluation, and may test products to verify claims. An inaccurate ACR can damage trust and create contractual risk. Good ACRs are based on real testing, name the product version and evaluation methods, and are honest about gaps with plans to fix them.
Criteria that commonly cause problems in SaaS products
- Keyboard access: every function, including drag and drop, menus and modals, must be operable without a mouse, with no keyboard traps.
- Focus visibility and order: users must see where focus is and move through the page in a logical order.
- Names, roles and values: custom controls must expose correct information to assistive technologies.
- Form labels and errors: fields need programmatic labels, and errors must be identified and described in text.
- Colour contrast: text and interface components need sufficient contrast.
- Alternatives for non-text content: images, icons and charts need text alternatives or accessible data tables.
- Dynamic updates: notifications and content changes must be announced to screen reader users.
- Data tables: complex tables need proper headers and relationships.
- Time limits: session timeouts need warnings and the ability to extend.
- Captions and transcripts for video and audio content.
Mobile apps and documents
Native mobile apps are software under the Revised 508 Standards and must apply the WCAG criteria and software requirements, using platform accessibility APIs so screen readers such as VoiceOver and TalkBack work correctly. Documents produced or distributed by a product, such as reports, invoices and exports, must also be accessible, which means generating tagged PDFs with correct reading order or offering accessible HTML alternatives.
What agencies ask for in procurement
Federal solicitations commonly ask vendors to provide an ACR for each product offered, describe how accessibility is built into development and testing, commit to remediating non-conformances within defined timeframes, and allow the agency to test products. Some agencies include accessibility in technical evaluation scoring, and contracts may require updated ACRs for new versions. Being able to answer these requests quickly, with credible evidence, gives vendors an advantage.
How to test for Section 508 conformance
- Automated testing with accessibility checkers to catch issues such as missing alternative text, low contrast and missing form labels. Automated tools find only a portion of issues.
- Manual testing of keyboard navigation, focus order, visible focus, headings, forms, error messages and dynamic content.
- Assistive technology testing with screen readers on desktop and mobile, screen magnifiers and voice control.
- Document testing for PDFs and office files, including tags, reading order and alternative text.
- Trusted tester methods: the Department of Homeland Security's Trusted Tester process is widely used by agencies for consistent Section 508 testing.
How vendors should prepare, step by step
- Adopt WCAG 2.2 AA as your design and development standard.
- Train designers and developers in accessible patterns.
- Build accessibility into the design system, with accessible components.
- Test continuously with automated checks in CI and manual reviews per release.
- Test with assistive technologies before major releases.
- Write an honest ACR for each product version using the VPAT template.
- Track and fix gaps with a published roadmap.
- Make documentation and support accessible.
Documentation you will need
- Accessibility Conformance Report for each product and version.
- Accessibility policy and standards.
- Test plans, results and tools used.
- Issue tracking and remediation roadmap.
- Accessible documentation and help materials.
- Training records for design and development teams.
Writing a credible Accessibility Conformance Report
Agencies read many ACRs and quickly spot generic ones. A credible report names the exact product and version evaluated, the date, the evaluation methods and tools, and the assistive technologies used. It uses "partially supports" and "does not support" where appropriate, with remarks that describe the specific limitation and any workaround, rather than marking everything as supported. It covers all applicable chapters, including documentation and support services, not only web content. Many vendors use the international edition of the VPAT so one report covers Section 508, WCAG and EN 301 549. Updating the ACR with each major release, and keeping old versions for reference, shows ongoing commitment.
Benefits beyond compliance
Accessible products reach more users, including the roughly one in four US adults who report having a disability, older users and people using devices in difficult conditions. Accessibility practices such as clear structure, good contrast and keyboard support also improve usability and search visibility for everyone. For vendors, a strong accessibility record opens doors with federal, state, education and enterprise buyers who increasingly require it.
Complaints and enforcement
Individuals with disabilities can file complaints with the agency about inaccessible ICT, and may bring civil actions. Agencies report on their Section 508 programmes, and the Department of Justice and GSA have published assessments of federal accessibility. For vendors, enforcement is mainly contractual: products that do not meet requirements may be rejected or require remediation.
Timeline and cost considerations
Building accessibility into new products adds modest cost when done from the start, mainly in design time and testing. Retrofitting an existing product can take months, depending on the number of issues and the design system. Creating a credible ACR requires a thorough evaluation, which may take several days to weeks for a complex application.
Common mistakes
- Claiming full support without real testing.
- Relying only on automated tools.
- Ignoring documents and PDFs generated by the product.
- Inaccessible custom components such as date pickers, menus and modals.
- Outdated ACRs that do not match the current version.
- Forgetting support and documentation requirements.
Best practices, tools and technologies
- Use semantic HTML and native controls before ARIA.
- Build an accessible component library and test it once, thoroughly.
- Add automated accessibility checks to CI and fail builds on regressions.
- Include people with disabilities in usability testing.
- Publish an accessibility statement with a feedback route.
We design and build accessible interfaces with semantic code, keyboard support and screen reader testing through our UI and UX design and web application development services.
How Section 508 relates to other laws and standards
| Law or standard | Relationship |
|---|---|
| WCAG | The technical basis; Section 508 incorporates WCAG 2.0 Level AA. |
| ADA | Civil rights law covering state and local government and businesses; Title II rule uses WCAG 2.1 AA. |
| European Accessibility Act | EU law using EN 301 549, which is harmonised with Section 508 and WCAG. |
| EN 301 549 | European ICT accessibility standard used in public procurement. |
| FedRAMP | Security authorization for federal cloud services; accessibility is a separate requirement. |
Real-world example
An Indian software company bids to supply a case management SaaS to a US federal agency. It runs a full accessibility evaluation using automated tools, manual keyboard testing and screen readers, finds issues in a custom data grid and PDF exports, fixes the grid using accessible patterns, tags generated PDFs, and produces an international edition VPAT covering Section 508, WCAG 2.2 and EN 301 549. The ACR honestly notes two partially supported criteria with a remediation date, which the agency accepts as part of its evaluation.
Next steps
- Adopt WCAG 2.2 AA as your standard.
- Evaluate your product thoroughly.
- Fix high-impact issues first.
- Write an honest ACR.
- Keep testing every release.
Frequently asked questions
What is Section 508?
A US law requiring federal agencies to make the ICT they develop, buy, maintain or use accessible to people with disabilities.
Does Section 508 apply to private companies?
Not directly, but vendors selling to federal agencies must meet its standards through procurement.
Which WCAG version does Section 508 use?
WCAG 2.0 Level A and AA, incorporated in the Revised 508 Standards in force since January 2018.
What is a VPAT?
The Voluntary Product Accessibility Template from ITI, used to create an Accessibility Conformance Report for Section 508, WCAG or EN 301 549.
What is an ACR?
An Accessibility Conformance Report documenting how a product conforms to accessibility standards.
Is there a Section 508 certification?
No. Vendors document conformance in ACRs, and agencies may test products.
Does meeting WCAG 2.2 AA satisfy Section 508?
Generally yes for web content and software criteria, since WCAG 2.2 AA includes the WCAG 2.0 AA criteria, though Section 508 has additional hardware, documentation and support requirements.
Do PDFs need to be accessible under Section 508?
Yes. Electronic documents covered by the standards must conform to WCAG criteria as applicable.
What is Trusted Tester?
A Department of Homeland Security testing process and certification for individuals, widely used by agencies for consistent Section 508 testing.
Is Section 508 being updated?
The Access Board has discussed updates, but as of October 2026 the 2017 standards remain in force.
Do native mobile apps need to meet Section 508?
Yes. Mobile apps are software under the standards and must apply the relevant WCAG criteria and platform accessibility features.
How often should an ACR be updated?
Whenever a significant new version is released, and at least when accessibility changes, so the report matches the product an agency is buying.
Official sources
- Section508.gov (US General Services Administration)
- Information and Communication Technology (ICT) standards and guidelines (US Access Board)
- ICT Standards and Guidelines final rule (18 January 2017) (Federal Register)
- Accessibility Conformance Report (ACR) (US General Services Administration)
- VPAT (Information Technology Industry Council)
Review history
Last reviewed Oct 30, 2026. Next scheduled review Oct 30, 2027, or sooner if the US Access Board proposes or adopts updated ICT standards.
- : First published.
This guide explains the official requirements in plain language. It is not legal advice and does not tell you whether your organisation is compliant. Confirm with qualified counsel, your auditor or an accredited certification body.