Section 508 Federal Compliance

Legal Basis

Section 508 of the Rehabilitation Act of 1973 was amended in 1998 to require that federal agencies make their electronic and information technology (EIT) accessible to people with disabilities. The Access Board published the Revised 508 Standards in January 2017, effective January 18, 2018. Those standards incorporate WCAG 2.0 Level AA by reference and align with the European standard EN 301 549.

Coverage extends beyond federal agencies. Any contractor developing, procuring, maintaining, or using EIT for a federal agency must meet the standard. This includes websites, web applications, software, hardware, kiosks, and documents. The obligation applies at the point of procurement, not only at delivery.

Technical Standard: WCAG 2.1 Level AA

The current technical baseline is WCAG 2.1 Level AA. The 2018 safe harbor provision allows legacy ICT to remain compliant to WCAG 2.0 AA if it was in conformance before January 2018 and has not been altered, but any alteration removes the safe harbor for the altered components.

WCAG 2.1 adds 17 success criteria to WCAG 2.0, addressing mobile accessibility, low vision, and cognitive disabilities. The criteria most frequently cited in federal audits are:

• 1.4.3 Contrast (Minimum): text must meet 4.5:1 contrast ratio (3:1 for large text) against its background
• 1.1.1 Non-text Content: all images must have text alternatives; decorative images must be marked with empty alt
• 2.4.4 Link Purpose: link text must be descriptive in context; "click here" and "read more" fail without accessible names
• 4.1.2 Name, Role, Value: all UI components must expose their name, role, and state to assistive technology through semantic HTML or ARIA
• 2.1.1 Keyboard: all functionality must be operable through keyboard alone
• 1.3.1 Info and Relationships: structure conveyed visually must be programmatically determinable

Scope: What Requires Compliance

Federal agencies must apply Section 508 to all EIT they develop, procure, maintain, or use. The practical scope for contractors includes:

• Public-facing websites and web applications
• Internal agency applications and intranets
• Software delivered under a contract
• Documents published or distributed to agency users (PDF, Word, Excel, PowerPoint)
• Video and multimedia content with audio
• Mobile applications
• Hardware with interactive interfaces

The micro-purchase threshold (currently $10,000 for most agencies) does not exempt procurement from Section 508; it exempts it from certain competition requirements. Accessibility requirements apply at all dollar thresholds.

VPATs and Accessibility Conformance Reports

A Voluntary Product Accessibility Template (VPAT) is a structured document vendors complete to disclose how their product meets Section 508 criteria. The completed document is called an Accessibility Conformance Report (ACR). Federal agencies require ACRs for ICT procurement.

VPATs are published by the IT Industry Council (ITI). Version 2.4 Rev 508 is the current template for federal procurement. An ACR has four possible conformance levels per criterion: Supports, Partially Supports, Does Not Support, and Not Applicable. "Not Applicable" carries an obligation to explain why the criterion does not apply. Stating "Supports" without testing is a liability, not a safe harbor.

A credible ACR requires actual testing: automated scanning, manual keyboard testing, and screen reader validation. Automated tools (axe, WAVE, Lighthouse) catch 30 to 40 percent of WCAG failures. The remainder require manual testing and assistive technology validation.

Audit Methodology

A Section 508 audit has three phases. The scope phase defines which pages, workflows, documents, and media fall within the audit boundary. The testing phase runs automated scans, manual keyboard traversal, and screen reader testing (NVDA + Chrome, JAWS + IE/Edge, VoiceOver + Safari on iOS). The reporting phase documents each failure with the violating criterion, the affected element, and a remediation recommendation.

Federal audit reports typically follow the ICT Testing Baseline for Web, published by the U.S. Access Board in coordination with GSA and DHS. The baseline maps 508 requirements to testable conditions and provides pass/fail criteria for each.

Most Common Failures in Federal Digital Products

Based on audit work across federal agency websites, these failures appear most frequently:

1. Insufficient color contrast: text elements, particularly labels, placeholders, and link text, failing the 4.5:1 minimum
2. Missing or generic link text: navigation links labeled "read more" or "click here" without surrounding context
3. Inaccessible PDFs: documents published without tagged structure, reading order, or alt text for figures
4. Custom UI components without ARIA: dropdowns, modals, tabs, and accordions built without appropriate roles and states
5. Missing focus indicators: keyboard focus outline suppressed by CSS without a replacement visible indicator
6. Unlabeled form fields: inputs associated visually with a label but lacking a programmatic label element or aria-labelledby
7. Video without captions: pre-recorded audio-visual content missing synchronized captions

Remediation Priorities

Not all failures carry equal risk. Prioritize by user impact and criticality of the affected workflow. A contrast failure on decorative text is lower severity than a contrast failure on a form submission button. An inaccessible login modal blocks access to the entire system.

Color contrast and focus visibility can typically be resolved through CSS alone. Semantic structure issues in custom components require HTML and JavaScript changes. PDF remediation is time-intensive and often requires Adobe Acrobat Pro or specialized tooling. Video captioning can be addressed at the platform level for platforms that support caption uploads.

Procurement Language

Solicitations for digital products should include Section 508 requirements in the Statement of Work, specify the required VPAT version (currently 2.4 Rev 508), identify which WCAG level applies (typically AA), and require an ACR at delivery. For ongoing contracts, include a provision requiring updated ACRs when the product is altered.

Do not accept a vendor VPAT as a substitute for independent testing. ACRs are self-certified disclosures, not compliance certificates. Build testing obligations into the contract period of performance.