A basic informational webpage can look accessible on a quick pass. A benefits application with branching questions, inline validation, and a digital signature step is a different animal, with more places to fail, and exactly the type of page that draws a formal complaint when it does.
Knowing what Section 508 requires, and how to judge software used to build public-facing forms, is the difference between getting it right once and rebuilding after an audit finding.
The legal baseline, and where it’s heading
Section 508 of the Rehabilitation Act obligates federal agencies to make their technology usable by employees and the public alike. Since January 2018, the Revised 508 Standards have pointed to WCAG 2.0 Level AA as the benchmark, covering web pages, electronic documents, and software interfaces.
That benchmark has since moved. WCAG 2.1 is now the version agencies are expected to meet, adding coverage for mobile interaction and cognitive accessibility that the 2.0 spec didn’t address. Separately, the Department of Justice issued a Title II rule under the ADA in April 2024 applying a nearly identical standard, WCAG 2.1 AA, to state and local government websites for the first time. Larger jurisdictions have until April 2026 to comply, smaller ones until April 2027.
Put together, nearly every layer of government now faces the same practical standard, regardless of which law technically applies. And because Section 508 also shapes procurement rules, an agency is responsible not just for accessible in-house development, but for what it buys.
Where forms specifically go wrong
Static pages tend to be forgiving, since a paragraph of text with a couple of images rarely trips up assistive technology. Forms are different, as every input, validation rule, and conditional field is another chance to break in a way mouse-driven testing won’t catch.
The recurring offenders in accessibility audits:
A field label that sits next to the input visually but isn’t tied to it in the markup looks fine to a sighted user, but leaves a screen reader with no announced purpose for the field.
No visible marker of keyboard focus, or one with too little contrast to see, leaves a user tabbing through a form unable to tell where they are.
Errors flagged only through color, typically a red outline with no accompanying text, give anyone who can’t perceive that shift no signal that something needs fixing.
Multi-step forms where a page transition, conditional section, or save-and-resume feature quietly breaks keyboard navigation, even when the first page worked.
CAPTCHA challenges and file upload widgets that assume a mouse and working vision are usually the last piece added and the first thing skipped in testing.
The technical requirements worth knowing by name
A short list of WCAG success criteria accounts for most 508 audit findings on forms.
Info and Relationships (1.3.1) governs whether a label is tied to its field, whether radio buttons or checkboxes are grouped, and whether headings follow a sensible hierarchy across the form.
Headings and Labels (2.4.6) requires a label to describe what the field is actually asking for. “Enter your information” fails. “Date of birth (MM/DD/YYYY)” passes.
Focus Visible (2.4.7) means keeping a clear, high-contrast indicator of keyboard focus, important on a form spanning several pages where losing your place is easy.
Error Identification (3.3.1) and Error Suggestion (3.3.3) together require an error described in text, linked to the field that caused it, and paired with a fix, not a vague banner saying the form has errors.
Contrast Minimum (1.4.3) covers body text, placeholder text, and error messaging, a frequent failure simply because default styling often isn’t checked for it.
Keyboard (2.1.1) requires every interactive element, including date pickers, dropdowns, and upload controls, to work without a mouse.
None of this demands unusual engineering skill, just a form-building tool that gets these details right automatically, and a habit of checking before a form ships rather than after a complaint.
Evaluating the platform you build on
Rather than hand-coding compliance into every form, agencies are better served scrutinizing the tool used to build forms. A few questions are worth asking before adopting one.
Does it produce WCAG 2.1 AA markup automatically, without a developer manually patching in the right attributes on every field? Manual remediation is fragile, and one rushed edit can break it.
Can the vendor produce a current Voluntary Product Accessibility Template, or VPAT? This walks through conformance criterion by criterion and is standard in federal procurement. A vendor without a current one shouldn’t be assumed compliant on marketing alone.
Has the platform been tested with screen readers and keyboard-only navigation, and can the vendor say which assistive technologies they used?
Does validation announce errors to assistive technology automatically, whether the form has three fields or thirty?
Is there a way to build and test a form privately before publishing, so problems surface before the public does?
If the form collects sensitive information, does the platform’s security posture hold up, including FedRAMP authorization where that level of review is expected? Agencies evaluating Section 508 compliant form software for permitting or constituent-facing applications should expect all of this bundled together, not pieced out across separate vendors.
Accessibility gets decided during procurement, not after launch
Most accessibility failures in government technology trace back to a procurement process that never asked the right questions upfront. Once signed, fixing a structural gap is far more expensive than catching it beforehand.
Make a current VPAT a requirement in any RFP for public-facing systems, push vendors to explain specifically how their platform avoids the patterns above rather than accepting a generic assurance, and build in an actual test, even an informal one, where someone navigates a sample form using only a keyboard and screen reader before launch.
Compliance erodes quietly after launch
A form that passes its initial review doesn’t necessarily stay compliant. A relabeled field, a new conditional section, or a swapped-out upload widget can quietly reintroduce a problem, especially when routine edits don’t get the scrutiny the original build did.
The fix is procedural: give review ownership to whoever is actually editing the form, not just the original builder, re-test with a screen reader after any structural change, and treat the VPAT as a living document, since one written two platform versions ago no longer describes what’s in production.
Agencies that treat 508 compliance as a single milestone tend to land back in remediation within a year or two. Those folding it into ongoing change management generally avoid that cycle.
The bottom line
No tool removes the need for good judgment on the content side. Someone still has to write clear labels, and whoever edits a form after launch needs to understand why it’s built the way it is. But the platform sets the ceiling on how accessible a form can realistically be.
If your agency has an accessibility deadline coming up, whether an internal 508 review or the DOJ’s Title II timeline, start by requesting a current VPAT, test the workflow with assistive technology, and confirm the platform’s security posture matches how sensitive the data is. Catching these gaps before launch is cheaper than fixing them after a complaint lands.
