How Section 508 Conformance Gates Public-Sector Deals

Federal agencies issue solicitations for software every week. These solicitations include security requirements, data handling standards, and infrastructure specifications. They also include Section 508 conformance requirements — and unlike many vendor questionnaire items that can be answered with a policy statement, 508 conformance is a testable, verifiable gate that has blocked contracts, triggered corrective action plans, and disqualified vendors from award.

For SaaS companies selling into federal, state, or local government, Section 508 is not a checkbox at the end of the procurement process. It is a procurement condition that must be satisfied before a contract can be awarded and maintained through the life of the engagement. Understanding what Section 508 actually requires, how it is tested, and how it relates to other public-sector compliance requirements — like the Authority to Operate process — determines whether a govtech sales motion succeeds or stalls.

What Section 508 Actually Requires

Section 508 of the Rehabilitation Act of 1973 was amended in 1998 to add requirements for electronic and information technology (EIT) procured by federal agencies. The statute requires that when a federal agency develops, procures, maintains, or uses EIT, that technology must be accessible to federal employees with disabilities and members of the public with disabilities who interact with federal agency services.

The phrase "electronic and information technology" covers web-based software, desktop applications, mobile apps, kiosks, telecommunications products, and video content — essentially any digital tool that an agency uses or offers. SaaS products sold to federal agencies fall squarely within this definition.

The 2017 Section 508 Refresh, published by the U.S. Access Board (36 CFR Part 1194), significantly modernized the technical standards. The original 2000-era standards had become outdated relative to modern web technology. The 2017 Refresh incorporated WCAG 2.0 Success Criteria at Level AA by reference, with the practical effect that WCAG 2.1 AA has become the operative standard as agencies apply current WCAG versions in their procurement criteria.

What this means concretely: a SaaS vendor selling to a federal agency must be able to demonstrate that their product meets the WCAG 2.1 AA success criteria — 50 specific testable requirements covering perceivability, operability, understandability, and robustness. The post on WCAG conformance roadmap for product teams provides a structured approach to working through these criteria at the feature level.

The VPAT and How Agencies Use It

The primary vehicle for documenting Section 508 conformance in procurement is the Voluntary Product Accessibility Template, or VPAT. The current version — VPAT 2.5 — is maintained by the IT Industry Council (ITI) and produces what is formally called an Accessibility Conformance Report (ACR).

A VPAT is a self-assessment. The vendor documents, for each relevant WCAG success criterion and Section 508 standard, whether their product conforms (Supports), partially conforms (Partially Supports), does not conform (Does Not Support), or whether the criterion does not apply (Not Applicable). Each entry should include a brief explanation of how the product meets or fails the criterion.

Agencies use VPATs to conduct their own Accessibility Conformance Review (ACR) during procurement. The GSA's Section 508 program guidance recommends that agencies review vendor VPATs as part of solicitation evaluation, and many Federal Acquisition Regulation (FAR) solicitations include VPAT submission as a mandatory deliverable. A missing or incomplete VPAT can delay procurement review even if the product itself is conformant.

The practical implication: a VPAT that honestly documents partial conformance is more useful to a procurement officer than a VPAT that claims full conformance without supporting evidence. Agencies conducting ACRs will test vendor claims, and discovered discrepancies between a VPAT and actual product behavior constitute a compliance risk that can trigger corrective action requirements. See the post on VPAT explained — what enterprise buyers actually check for a buyer-side view of how VPATs are evaluated.

Section 508 and the ATO Process: Adjacent but Separate

The Authority to Operate (ATO) process governs whether a federal information system has been authorized to operate based on a security risk assessment. It is governed by the Federal Information Security Modernization Act (FISMA) and implemented through the NIST Risk Management Framework (RMF), documented in NIST Special Publication 800-37.

Section 508 and the ATO process are separate legal frameworks, administered by different offices, with different standards and different outcomes. A vendor can hold a full ATO and still fail Section 508 review. A vendor with strong WCAG conformance can be blocked from federal use while their ATO is pending. They are parallel gates, not sequential ones.

In practice, larger federal procurements require both. The agency CISO or ISSO (Information System Security Officer) owns the ATO process, which includes system categorization, security controls selection (NIST 800-53), and continuous monitoring. The agency Section 508 Coordinator — typically in the IT or civil rights office — owns accessibility review. Both offices must sign off before a contract can move to award.

SaaS vendors selling to federal agencies often encounter 508 review during the acquisition phase, while ATO review may continue into post-award. For many SaaS deployments, the vendor's product is reviewed under a government-hosted or contractor-managed ATO; 508 review is almost always the vendor's direct responsibility. The post on government SaaS sales cycle provides the full procurement sequence, including where each gate falls in the federal acquisition timeline.

What "Equal Access" Means for SaaS in Practice

Section 508 requires equivalent access — not identical access. This distinction matters for product decisions.

A sighted user who clicks a button and gets an immediate result has equivalent access to a blind user who navigates to the same button via keyboard, hears it announced by a screen reader, activates it, and receives the same result. The interaction modality differs, but the outcome is equivalent. Section 508 does not require that the screen reader experience be visually indistinguishable from the sighted experience.

In practice, equivalent access has several concrete implications for SaaS product design:

Navigation must be possible without a mouse. Every interactive element must be reachable via keyboard, in a logical tab order, with visible focus indicators. Forms must have programmatically associated labels. Images must have meaningful alternative text. Data tables must have headers and relationships marked up in HTML so screen readers can interpret them. Error messages must identify the specific field in error and provide instructions, not just red color indicators.

Timing-dependent features — sessions that expire, animations that auto-play, carousels that rotate — must be pausable, stoppable, or extendable. A user with a motor disability who needs more time to complete a form cannot be locked out by a 60-second timeout without a mechanism to extend it.

Color cannot be the sole conveyor of information. A status indicator that is green for success and red for failure with no text label fails Section 508 for users with color vision deficiency, which affects approximately 8% of male users.

The post on mapping accessibility debt before deal blockers covers how to audit an existing product for 508-relevant issues before entering a procurement cycle, rather than discovering gaps during the agency's ACR.

State Laws That Mirror and Extend Section 508

Section 508 applies to federal agencies and their direct vendors. But a parallel legal landscape at the state level extends similar requirements to state agency technology purchases, covering a large additional segment of government software procurement.

California Government Code Section 11546.7 requires state agencies to comply with WCAG 2.0 AA or successor standards in their web-based technology procurement. California has one of the largest state IT budgets in the country — vendors selling to California state agencies face substantively the same accessibility requirements as federal vendors.

Texas Administrative Code Title 1, Part 10, Chapter 206 and Chapter 213 establish state-level EIT accessibility standards derived from Section 508, applied to Texas state agencies. The Texas Department of Information Resources (DIR) administers the program and maintains a vendor-facing accessibility assessment process for products on state contract vehicles.

New York Technology Law Section 103-d requires that state agency websites and digital services conform to WCAG 2.1 AA. Illinois enacted the Illinois Information Technology Accessibility Act (IITAA) with a standards framework maintained by the Illinois Department of Central Management Services.

Beyond these, Washington, Virginia, Maryland, Colorado, and Minnesota have enacted various state-level accessibility statutes or executive orders that affect public-sector software procurement. The cumulative geographic scope is substantial: a SaaS vendor pursuing state and local government business across multiple states is likely subject to accessibility requirements in more than half of their target markets.

For vendors evaluating the govtech market, see the posts on govtech SaaS procurement cycle and SaaS FedRAMP vs StateVRAMP decision for broader public-sector sales strategy context.

How Agencies Actually Test for Conformance

Federal agencies use three primary testing mechanisms for Section 508 conformance: automated scanning, manual testing, and the DHS Trusted Tester methodology.

Automated scanning tools — Axe, WAVE, Deque, SiteImprove — can identify a subset of WCAG failures rapidly. The WebAIM Million study, which analyzes WCAG failures on the top one million websites, consistently finds that automated tools detect approximately 25–35% of all WCAG issues. Automated scanning is a necessary first step but insufficient for procurement compliance, because the majority of WCAG failures require human judgment to identify.

Manual testing fills the gap. A trained accessibility auditor using screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, and browser-based accessibility inspection tools can identify issues that automated scanners miss: focus order problems, inadequate screen reader announcements, form interaction failures, and timing issues. Manual testing is time-intensive and requires skilled testers, which is why agencies often rely on their own Section 508 coordinators or contracted accessibility vendors.

The DHS Trusted Tester program standardizes manual testing methodology across government. Individuals who complete Trusted Tester certification are trained to perform reproducible Section 508 conformance tests using a defined procedure set, producing results that different testers should reach consistently. The GSA Section 508 program page documents which agencies require Trusted Tester methodology for vendor submissions. Vendors whose products have already been evaluated by a Trusted Tester-certified auditor can submit those results, which may accelerate agency ACR timelines.

The practical vendor strategy: run automated scanning first to identify low-hanging issues, conduct targeted manual testing on the most common user workflows, and consider engaging a Trusted Tester-certified accessibility firm to produce a defensible ACR before entering federal procurement. Submitting a clean, credible VPAT backed by third-party testing is significantly more persuasive in a procurement review than a vendor-only self-assessment.

The Dollar Threshold Question — and Why It Doesn't Exist

A common assumption among software vendors entering the public-sector market is that Section 508 only applies above certain contract value thresholds, similar to how other federal acquisition regulations have simplified acquisition thresholds. This assumption is incorrect.

Section 508 applies to all federal EIT procurement, regardless of contract value. There is no dollar safe harbor. A $15,000 task order for web-based project management software triggers the same Section 508 obligations as a $15 million enterprise software contract. The only exceptions are narrow: national security systems as defined by 40 USC 11103 are excluded, and agencies can invoke an "undue burden" exception when conformance would require fundamental alteration of the product or impose extraordinary difficulty or expense. In practice, the undue burden exception is infrequently invoked and requires documented justification from the agency head.

The absence of a dollar threshold has meaningful implications for SaaS vendors pursuing small-agency or micro-agency government customers. A community college district, a county health department, a regional transit authority — all of these entities may be subject to state-level 508 equivalents even if they are below federal agency status. Assuming that smaller contracts or smaller agencies do not require accessibility conformance is a frequent source of surprise in govtech sales.

For the full procurement context, see the post on enterprise SaaS procurement tactics which covers threshold-based procurement rules and when simplified acquisition procedures apply to other (non-508) requirements.

Conclusion

Section 508 conformance is not a soft requirement that can be addressed with a letter of intent or a roadmap commitment. It is a statutory gate on federal EIT procurement with no dollar threshold exception, backed by testable WCAG 2.1 AA technical standards, and enforced through agency Accessibility Conformance Reviews that will test what a VPAT claims.

The 2017 Section 508 Refresh modernized the technical standard, aligning it with WCAG and making automated testing more relevant — but also raising the bar because WCAG 2.1 AA is a higher standard than the original 2000-era Section 508 provisions. State-level equivalents in California, Texas, New York, Illinois, and more than a dozen other states extend these requirements beyond the federal buyer to a large segment of state and local government procurement.

For SaaS vendors with govtech ambitions, the path forward is clear: invest in accessibility auditing before entering a procurement cycle, produce a VPAT that accurately represents the product's conformance state, and build a product roadmap that closes identified gaps. A vendor with credible 508 documentation and a defensible VPAT will move through procurement reviews faster than a vendor who encounters these requirements for the first time mid-evaluation.

The vendors who treat Section 508 as an engineering quality standard — not an afterthought — are the ones who close public-sector deals without stalls.