Section 508 Accessibility Compliance

Section 508 Requirements Overview

Section 508 of the Rehabilitation Act (29 U.S.C. 794d) requires federal agencies to ensure that the ICT they develop, procure, maintain, or use is accessible to people with disabilities. This applies to both employees with disabilities and members of the public who interact with federal technology. The law affects software, websites, hardware, electronic documents, telecommunications equipment, and multimedia.

The Revised Section 508 Standards (effective January 2018) incorporate the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA as the baseline accessibility standard for web content and software. Many agencies now reference WCAG 2.1 or WCAG 2.2 in solicitations, anticipating future regulatory updates.

From a procurement perspective, Section 508 compliance is typically evaluated as a pass/fail gate during technical evaluation. Solicitations for ICT products and services include FAR 52.204-25 (Prohibition on Contracting for Certain Telecommunications) and agency-specific clauses requiring accessibility conformance documentation. Failure to provide adequate accessibility documentation can render an offer technically unacceptable.

VPAT (Voluntary Product Accessibility Template)

The Voluntary Product Accessibility Template (VPAT) is the standard document used to communicate a product's Section 508 conformance. Created by the Information Technology Industry Council (ITI), the VPAT produces an Accessibility Conformance Report (ACR) that agencies use to evaluate whether a product meets their accessibility requirements.

The current VPAT version (2.5) includes templates for WCAG 2.x, Revised Section 508, and EN 301 549 (European accessibility standard). Most federal procurements require the WCAG 2.x and Revised Section 508 edition. The VPAT should document conformance for every applicable success criterion, using standardized conformance levels:

• Supports: The product fully meets the criterion
• Partially Supports: Some functionality meets the criterion, but gaps exist
• Does Not Support: The majority of functionality does not meet the criterion
• Not Applicable: The criterion is not relevant to the product

A well-prepared VPAT is specific, honest, and includes detailed remarks explaining any partial conformance or known issues. Agencies are increasingly skeptical of VPATs that claim full support across all criteria without substantive remarks — realistic, transparent reporting builds credibility.

ICT Accessibility Standards

The Revised Section 508 Standards apply different requirements depending on the type of ICT:

Web Content and Software (WCAG 2.0 AA)

All web content and software user interfaces must conform to WCAG 2.0 Level AA success criteria. This covers four principles: Perceivable (text alternatives, captions, adaptable content), Operable (keyboard navigation, timing, seizure prevention), Understandable (readable, predictable, input assistance), and Robust (compatible with assistive technologies). Key requirements include keyboard accessibility, color contrast ratios (4.5:1 minimum for normal text), form labels, error identification, and ARIA attributes for dynamic content.

Hardware

Hardware products must be operable without vision, with limited vision, without perception of color, without hearing, with limited hearing, without speech, and with limited reach or strength. Requirements include tactile controls, audible and visual indicators, and physical accessibility of operable parts.

Electronic Documents

Electronic documents (PDFs, Word documents, presentations, spreadsheets) must be accessible. This means proper heading structures, alternative text for images, tagged PDF structure, accessible tables, and readable fonts. Documents must be navigable by screen readers and support text reflow.

Telecommunications

Telecommunications products must support real-time text (RTT), be hearing aid compatible, and provide volume control. Video conferencing solutions must support captioning and visual indicators for audio alerts.

Testing and Compliance Documentation

Effective Section 508 testing combines automated tools with manual evaluation. Automated tools (axe, WAVE, Lighthouse) can identify approximately 30-40% of accessibility issues — primarily structural issues like missing alt text, broken form labels, and contrast failures. The remaining issues require manual testing with assistive technologies.

The DHS Trusted Tester Process is the federal government's standard methodology for Section 508 conformance testing. Trusted Testers follow a structured test process covering all applicable WCAG criteria, using specific tools (ANDI, Color Contrast Analyzer) and assistive technologies (JAWS, NVDA, VoiceOver). Agencies increasingly require Trusted Tester certification or equivalent rigor in accessibility test reports.

Documentation you should prepare for federal ICT procurements:

• Current VPAT/ACR for each product or service offered
• Accessibility test report from qualified testers
• Remediation roadmap for any known accessibility gaps
• Accessibility conformance statement describing your testing methodology
• Evidence of ongoing accessibility testing in your development process

Common Pitfalls

• ✕

  Submitting an outdated VPAT. Agencies expect VPATs to reflect the current version of your product. A VPAT from two years ago against a deprecated product version will be questioned or rejected.

• ✕

  Claiming full conformance without evidence. A VPAT that marks "Supports" for every criterion without detailed remarks raises red flags. Evaluators know that no complex product achieves perfect conformance.

• ✕

  Ignoring dynamic content. Single-page applications, modal dialogs, and AJAX-updated content are among the most common accessibility failures. Test interactive components with screen readers, not just static pages.

• ✕

  Treating accessibility as an afterthought. Retrofitting accessibility is far more expensive than building it in from the start. Integrate accessibility testing into your CI/CD pipeline and design process.

• ✕

  Relying solely on automated testing. Automated tools catch structural issues but miss context-dependent problems like meaningful alt text, logical reading order, and keyboard trap scenarios. Manual testing with assistive technology is required.

• ✕

  Forgetting about documents. PDFs, training materials, and user guides must also be accessible. Many proposals fail because the technical approach document itself is an inaccessible PDF.