Section 508 & WCAG 2.2 Compliance for Federal Contractors (2026)
If you deliver software, websites, documents, or multimedia to federal agencies, accessibility is a contractual obligation — not a nice-to-have. Agencies are tightening 508 acceptance criteria, and 'we'll fix it post-award' is a fast path to cure notices and withheld payments.
June 15, 202614 min readBy Thorium DC
Section 508 of the Rehabilitation Act requires federal agencies to make their information and communications technology (ICT) accessible to people with disabilities. When you are the contractor building that ICT, the requirement flows down to you — through FAR clauses, PWS/SOW language, and acceptance testing gates that can block deployment.
In 2026, the baseline is no longer “we run a WAVE scan.” Contracting officers and 508 coordinators expect WCAG 2.1 AA at minimum, with increasing references to WCAG 2.2 AA for new development. They expect a current VPAT/ACR, evidence of manual testing with assistive technology, and a sustainment plan that does not let accessibility regress every sprint.
What is Section 508?
Section 508 applies to all federal agencies when they develop, procure, maintain, or use ICT. The 2018 “508 Refresh” aligned federal requirements with international standards, specifically incorporating WCAG 2.0 Level AA for web content and establishing the Revised 508 Standards (36 CFR Part 1194).
Covered ICT
- • Websites and web applications
- • Software (desktop, mobile, SaaS)
- • Electronic documents (PDF, Word, PowerPoint)
- • Multimedia (video with captions/audio description)
- • Hardware with user interfaces (kiosks, ATMs)
Key enforcement mechanism
- • FAR 52.239-1 Privacy or Security Safeguards (related)
- • FAR 11.002(f) — ICT accessibility in acquisitions
- • Agency-specific 508 clauses in solicitations
- • Acceptance testing before ATO or public launch
- • False Claims Act exposure for misrepresented conformance
WCAG 2.2 AA: what changed
WCAG 2.2 (W3C Recommendation, 2023) adds nine success criteria at Levels A and AA. Federal solicitations written in 2025–2026 increasingly cite 2.2 for new builds. Even when the formal standard references 2.0, agency 508 coordinators often evaluate against 2.1/2.2 as best practice.
2.4.11Focus Not Obscured (Minimum)
Keyboard users must see focused elements — modals and sticky headers often fail this.
2.4.12Focus Not Obscured (Enhanced)
Stricter focus visibility; often required for high-traffic citizen-facing apps.
2.4.13Focus Appearance
Focus indicators need sufficient size and contrast — custom design systems frequently miss this.
2.5.7Dragging Movements
Drag-and-drop interfaces need keyboard-accessible alternatives.
2.5.8Target Size (Minimum)
Interactive targets must be at least 24×24 CSS pixels with limited exceptions.
3.2.6Consistent Help
Help mechanisms must appear in the same relative location across pages.
3.3.7Redundant Entry
Users should not re-enter information already provided in the same process.
3.3.8Accessible Authentication (Minimum)
Cognitive function tests (CAPTCHA puzzles) cannot be required without alternatives.
3.3.9Accessible Authentication (Enhanced)
Object recognition and puzzle CAPTCHAs are prohibited without alternatives.
Practical guidance: Target WCAG 2.2 AA for any federal-facing product in active development. Retrofitting 2.2 criteria later costs 3–5× more than building them into your design system from sprint one.
Who must comply
Prime contractors delivering ICT
Responsible for end-to-end conformance of delivered product — including subcontractor components. You cannot pass liability down without oversight.
Subcontractors building UI, content, or documents
Must meet SOW accessibility requirements and provide component-level VPAT sections. Primes are increasingly flow down 508 testing in subcontract attachments.
SaaS vendors selling into federal
Agency ATO and procurement both require ACR. 'We have an accessibility page' is insufficient — buyers want criterion-by-criterion conformance tables.
Systems integrators modernizing legacy apps
Incremental releases must not reduce accessibility. Document baseline conformance before migration; compare each release.
FAR clauses and solicitation language
Watch for these in RFPs, RFQs, and task orders:
| Reference | What it means for you |
|---|---|
| FAR 39.204 — ICT accessibility | Agencies must ensure ICT is accessible. Flows into evaluation criteria and acceptance. |
| Section 508 compliance statement in PWS | Explicit WCAG version, testing method, and deliverable schedule (VPAT, test reports). |
| Acceptance criteria tied to 508 | Payment milestones may require 508 sign-off from agency coordinator — plan lead time. |
| Agency-specific supplements (e.g., HHS, VA, DHS) | Stricter timelines, mandatory tools (e.g., ANDI, axe), or Section 504 overlap. |
During proposal stage: if the solicitation is silent on WCAG version, propose 2.2 AA explicitly. It signals maturity and avoids rework when the COR adds it at kickoff.
VPAT and ACR requirements
The ITI VPAT® template is the industry standard for documenting conformance with 508, WCAG, EN 301 549, and international standards. When completed for a federal buyer, it becomes an Accessibility Conformance Report (ACR).
1. Select the right VPAT edition
Use VPAT 2.5 (or current) with the WCAG 2.2 column for new development. Match the edition the agency requests in the solicitation.
2. Test before you write
ACR rows must reflect actual test results — not engineering assumptions. Automated tools cover ~30–40% of WCAG; manual AT testing is required.
3. Be honest about 'Partially Supports' and 'Not Supported'
Overstating conformance is worse than documenting gaps with remediation dates. Agency coordinators compare ACRs to their own tests.
4. Include version and date
ACR must match the build delivered. Re-issue with every major release — treat it like a security scan artifact.
5. Cover all modalities
Web, PDF, mobile, and embedded help content each need evaluation. PDFs are the most common surprise failure in federal deliverables.
Testing methodology that passes agency review
A defensible 508 test report includes three layers:
Automated scanning
axe DevTools, WAVE, Lighthouse, Pa11y CI
Regression in CI/CD on every PR; catches ~30–40% of issues
Limit: Cannot verify focus order, screen reader context, or cognitive flow
Manual expert review
Keyboard-only navigation, zoom to 200%, color contrast analyzers
All templates, critical user paths, form error handling
Limit: Requires trained 508 testers — not generic QA
Assistive technology (AT) testing
JAWS, NVDA, VoiceOver, TalkBack, Dragon NaturallySpeaking
Representative tasks: login, search, submit form, complete transaction
Limit: Time-intensive; prioritize by user volume and legal risk
Document test environments (browser/OS/AT versions), tester qualifications, and defect severity mapping. Agency 508 coordinators reuse your reports during ATO — incomplete methodology sections trigger retest requests.
Remediation roadmap
Prioritize fixes by user impact and contractual deadline:
P0 — Blockers
No keyboard access to primary workflows, missing form labels, video without captions, authentication CAPTCHA with no alternative
Fix before any public or production deployment
P1 — High impact
Insufficient color contrast on primary UI, focus traps in modals, inaccessible data tables, PDFs without tags
Within 30 days of discovery or per contract cure period
P2 — Medium
Inconsistent heading hierarchy, redundant entry in multi-step forms, small touch targets below 24px
Next release train; document in POA&M
P3 — Low / enhancement
Enhanced focus appearance (2.4.12), consistent help placement polish
Backlog; align with design system upgrades
Sustainment in agile delivery
Most 508 failures on federal projects happen after initial conformance — when new features ship without accessibility acceptance criteria.
- ✓Definition of Done includes WCAG 2.2 AA — no story closes without keyboard and screen reader check on changed UI
- ✓Pa11y or axe CI gates block merges on critical violations
- ✓Design system components ship with documented ARIA patterns and passing tests
- ✓508 regression suite runs on staging before each sprint demo
- ✓Third-party component libraries (charts, maps, rich text editors) vetted for VPAT before adoption
- ✓Content authors trained on accessible PDF and document structure — not just developers
DC GovCon context
The National Capital Region accounts for roughly $50B+ in federal contract spending annually. Accessibility requirements show up across civilian agencies headquartered in DC, Maryland, and Virginia — not just public-facing citizen portals.
- HHS and CMS. Health-related public-facing systems face dual pressure from Section 508 and healthcare accessibility expectations. WCAG failures on benefits portals draw congressional scrutiny.
- DHS and intelligence community. Classified systems still have 508 obligations for unclassified portions, intranet tools, and training platforms. Do not assume 508 stops at the classification boundary.
- GSA and Login.gov ecosystem. Identity and shared services set de facto standards. If you integrate with federal identity providers, authentication flows must meet WCAG 2.2 accessible authentication criteria.
- State and local flow-down. DC government and Maryland/Virginia state contracts increasingly reference federal 508 standards for IT procurements — especially Medicaid and public benefits systems.
Realistic cost and timeline
VPAT/ACR for existing SaaS (single app)
$15k–$40k
4–8 weeks
Audit, remediate P0/P1, deliver ACR
New federal web app (build accessible)
12–18% of dev budget
Ongoing per sprint
Design system, CI gates, AT testing baked in
Legacy remediation (100+ page app)
$75k–$250k+
3–9 months
Depends on tech stack, PDF volume, and content debt
Budget 8–12% of annual sustainment for accessibility regression testing on active federal products. Skipping this line item is how ACRs go stale within two quarters.
FAQ
Is WCAG 2.2 required if the solicitation says WCAG 2.0?
Legally, you must meet the cited standard. Practically, agency 508 coordinators often test against newer criteria. Clarify at pre-proposal Q&A; proposing 2.2 AA when 2.0 is cited is usually acceptable and appreciated.
Can automated testing alone satisfy Section 508?
No. Federal testing protocols require manual and assistive technology evaluation for conformance claims. Automated tools are a first pass, not a certificate.
Who signs the ACR?
A qualified accessibility lead — often a Section 508 program manager, IAAP-certified tester, or third-party auditor. Engineering managers should not sign without test evidence.
What happens if we fail 508 acceptance?
Typical outcomes: cure notice with 30–90 day remediation window, withheld payments, negative CPARS ratings, and exclusion from option years. Repeated failures can trigger termination for default.
Does Section 508 apply to internal admin tools?
Yes, if the agency uses the tool and it is ICT procured or developed with federal funds. Employee-facing applications are explicitly in scope under the Revised 508 Standards.
Building for federal? Start with accessibility in the architecture.
Thorium DC designs and builds WCAG 2.2–conformant web applications for federal contractors — from VPAT-ready design systems through CI-integrated testing and ACR delivery.