Government Form Accessibility: How to Meet ADA and Section 508 Standards

Accessibility is a legal requirement for government digital services, not a design preference. Under Section 508 of the Rehabilitation Act and Title II of the Americans with Disabilities Act, federal, state, and local government agencies are required to make their electronic information and technology accessible to individuals with disabilities.

For digital forms specifically, that obligation is concrete. A constituent who uses a screen reader, relies on keyboard navigation, or has low vision should be able to complete a permit application, benefit request, or service form with the same accuracy and efficiency as any other user.

Here is what accessible government forms actually require, organized by the criteria that most frequently drive compliance gaps.

1. WCAG 2.1 AA Is the Applicable Standard

The Web Content Accessibility Guidelines 2.1 at Level AA is the accepted technical standard for Section 508 compliance under the Revised 508 Standards issued by the U.S. Access Board in 2018. WCAG 2.1 AA incorporates and extends the earlier WCAG 2.0 standard and adds specific criteria for mobile accessibility and cognitive accessibility.

State and local government agencies subject to ADA Title II are held to effectively the same standard. The Department of Justice’s 2024 rule clarifying Title II web accessibility requirements specifically references WCAG 2.1 Level AA as the applicable technical specification.

Forms that were built to WCAG 2.0 standards need to be reviewed against the additional WCAG 2.1 success criteria to confirm continued compliance, particularly for mobile and touch interface accessibility.

2. All Form Fields Must Have Programmatic Labels

Every form field must have a label that is programmatically associated with the input element, not just visually positioned near it. A label that is styled to appear near a field but is not connected through a ‘for’ attribute or ARIA labeling is invisible to screen readers, which means a screen reader user cannot tell what information a field is asking for.

Placeholder text does not substitute for a label. Placeholder text disappears when a user starts typing, leaving screen reader users without field context. Every input field needs a persistent, programmatically associated label that remains available to assistive technology throughout the interaction.

For grouped fields like radio buttons or checkboxes, the group needs a fieldset and legend element that provides context for the group, in addition to individual labels for each option.

3. Error Messages Must Be Specific and Programmatically Associated

When a form field fails validation, the error message needs to meet two requirements. It must be specific enough for the user to understand what is wrong and how to fix it. And it must be programmatically associated with the field it refers to, so a screen reader user who navigates to the field hears the error in context.

An error message that says ‘Invalid input’ does not tell the user what is wrong. An error that says ‘Enter a phone number in the format 555-555-5555’ gives the user the information needed to correct the input. Specificity in error messages reduces re-submission rates and abandonment for all users, but it is legally required for screen reader accessibility.

ARIA live regions can be used to announce errors dynamically when they appear, so users are notified of validation failures without having to navigate the entire form to find them.

4. The Entire Form Must Be Keyboard Navigable

Users who cannot use a mouse, including users with motor disabilities and users who rely on keyboard-based assistive technology, must be able to complete every form interaction using the keyboard alone. That means tab order through the form must be logical and follow the visual reading order, all interactive elements must be focusable and activatable via keyboard, and no interactions should require mouse-specific events like hover or click.

Focus indicators must be visible. When a keyboard user tabs to a form element, there must be a visible indication of which element has focus. The WCAG 2.1 standard requires a minimum focus indicator contrast ratio, and designs that hide or minimize focus rings for aesthetic reasons create compliance failures for keyboard-dependent users.

Custom interactive elements, including date pickers, file upload controls, and dropdown menus built with non-standard HTML, must implement the appropriate ARIA patterns to ensure keyboard accessibility and screen reader compatibility.

5. Color Contrast Must Meet Minimum Ratios

Text and interface components must meet minimum color contrast ratios to be readable by users with low vision or color blindness. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). UI components and states including focus indicators, error icons, and required field markers must also meet the 3:1 minimum.

Color alone cannot be used to convey information. A required field that is indicated only by a red border, with no text label or icon, fails accessibility requirements. Required fields must be indicated by text (such as an asterisk with a legend explaining its meaning) in addition to any color-based styling.

Error states that rely only on red color to indicate a problem fail the same criterion. Error conditions should be communicated through text, iconography, or both, in addition to color changes.

6. Forms Must Work on Mobile and Touch Interfaces

WCAG 2.1 added several success criteria specifically addressing mobile accessibility that were not in the earlier 2.0 standard. For government forms, which an increasing share of constituents access on mobile devices, these criteria are practically significant.

Touch targets must be large enough to activate accurately. WCAG 2.1 recommends a minimum touch target size of 44 by 44 CSS pixels for interactive elements. Small checkboxes, radio buttons, and select fields that are difficult to activate on a touchscreen create barriers for users with motor control limitations.

Forms must not require specific orientation. A form that only works in landscape or portrait mode excludes users whose devices are mounted in a fixed orientation for accessibility reasons.

7. Time Limits Must Be Adjustable or Avoidable

If a form session expires after a period of inactivity, users must be warned before the time limit expires and given the opportunity to extend it. A user with a cognitive disability who takes longer to complete a form, or a screen reader user navigating a complex form carefully, should not lose their work because the session timed out without adequate warning.

For government forms with particularly complex or lengthy data entry requirements, consider whether session time limits are necessary at all. If the information security rationale for a short session timeout does not require it for the specific form type, allowing longer sessions or offering a save-and-return option eliminates this barrier entirely.

8. Request a VPAT from Any Third-Party Form Platform

If your agency uses a third-party platform to build and host public-facing forms, the platform’s accessibility posture directly affects your agency’s compliance. A form built on a platform that does not produce accessible output will fail accessibility requirements regardless of how carefully the form itself is designed.

Ask vendors for a Voluntary Product Accessibility Template (VPAT) documenting their conformance with the Revised 508 Standards and WCAG 2.1 AA. A VPAT is the standard format for accessibility documentation in federal procurement and provides a structured basis for evaluation. Vendors that cannot produce a current VPAT should be treated as unverified for accessibility compliance purposes.

FormAssembly is designed to produce Section 508 and WCAG 2.1-compliant form output by default. Government customers can request FormAssembly’s VPAT to support procurement review and ATO documentation.