Section 508 and WCAG get used interchangeably in procurement conversations, and that shorthand causes real confusion. Section 508 is a law. WCAG is a technical standard. The two are connected, but a form that satisfies one section of Section 508 can still fail a WCAG success criterion, and buyers evaluating form platforms need to know which question they are actually asking.
For government agencies and public higher education institutions, this distinction shows up in every procurement cycle. RFPs cite Section 508. Accessibility audits cite WCAG. Vendors need to answer to both.
What Section 508 Actually Requires
Section 508 of the Rehabilitation Act requires federal agencies, and by extension many state and local governments through their own procurement rules, to make electronic and information technology accessible to people with disabilities. The law itself does not spell out pixel-level requirements. Instead, the current regulation incorporates WCAG 2.0 Level AA as the technical standard federal agencies must meet, a change finalized when the U.S. Access Board updated the Section 508 standards in 2017.
That means Section 508 compliance today is, in practice, WCAG 2.0 AA compliance. Some agencies and states have since moved their internal policy to reference WCAG 2.1 or 2.2, which add criteria for mobile accessibility and cognitive load that 2.0 does not cover. A vendor that only meets the letter of the 2017 regulation may still fall short of what an individual agency’s current policy expects.
What WCAG 2.1 and 2.2 Add for Forms
WCAG organizes its success criteria under four principles: perceivable, operable, understandable, and robust. Forms touch all four, but a handful of criteria account for most real-world failures.
Every form field needs a programmatically associated label, not just placeholder text that disappears once a user starts typing. Error messages need to identify which field failed and why, in text a screen reader can announce, not just a red border. Every interactive element, including custom dropdowns, date pickers, and file upload controls, needs to be operable from a keyboard alone. Color cannot be the only way a required field or an error state is indicated. WCAG 2.2 adds criteria specifically aimed at forms, including a rule against asking users to re-enter information they already provided earlier in the same process.
Where Off-the-Shelf Form Builders Typically Fail
Consumer-grade form tools are usually built for speed of design, not for accessibility, and it shows in predictable places. Drag-and-drop builders generate div-based layouts instead of semantic form elements, which breaks screen reader navigation. Conditional logic that shows and hides fields dynamically often fails to update the accessibility tree, so a screen reader user does not know a new required field appeared. Custom-styled checkboxes and radio buttons frequently lose their keyboard focus states in the process of restyling them to match a brand.
None of these are edge cases. They are the specific findings that show up in third-party accessibility audits of government and higher ed intake forms, and they are the reason a platform’s accessibility claims need to be verified rather than taken at face value.
How Buyers Verify an Accessibility Claim
A vendor’s word that its product is accessible is not a standard. The standard artifact is a Voluntary Product Accessibility Template, or VPAT, which produces an Accessibility Conformance Report mapping the product against WCAG success criteria one by one. A current, third-party-informed VPAT is the baseline document procurement teams should request before shortlisting any form platform for a government or higher ed deployment.
Buyers should also ask a more specific question: does the accessibility conformance apply to the form-building interface, the published forms end users fill out, or both? A tool can have an accessible admin dashboard and still generate forms that fail WCAG for the citizen or student filling them out. The published output is what matters for compliance exposure.
Where Accessibility Meets Procurement Requirements
For government buyers, Section 508 conformance sits alongside FedRAMP authorization as a standard procurement gate, and the two get evaluated together in most RFPs for citizen-facing digital services. For higher ed, accessibility requirements increasingly extend beyond public institutions as private colleges face their own legal exposure under Title II and Title III interpretations following recent Department of Justice rule changes.
The practical effect is the same in both verticals: accessibility is no longer a nice-to-have layered on top of a form platform selection. It is a gating requirement checked earlier in the evaluation than most vendors expect, alongside the broader infrastructure question of whether a form platform connects cleanly to the agency’s core systems at all.
Where FormAssembly Fits
FormAssembly forms are built on semantic HTML with programmatically associated labels, keyboard-operable custom controls, and error messaging designed to work with assistive technology, supported by a current VPAT covering both the form-building interface and published forms. That accessibility posture sits alongside FedRAMP authorization through FedHIVE, giving government and higher ed procurement teams a single platform that clears both the technical accessibility bar and the security authorization bar in the same evaluation.
Try it out for yourself.
Book a personalized demo or request a trial of the platform today.
