Secure Forms

Building accessible forms is one of the hardest problems in web development. Every input needs proper labeling. Every validation error needs to be announced to screen readers. Focus order must be logical. Color contrast must meet thresholds. And all of this must work across browsers, assistive technologies, and device types. Most teams either skip accessibility entirely or spend weeks retrofitting forms after an audit failure.

Form.io addresses this through the Accessibility Compliance Module, a separately licensable add-on that enables WCAG 2.1 AA compliant components and renders forms using markup designed for assistive technology compatibility. The module does not magically make any form accessible. It provides the infrastructure that makes building accessible forms possible without starting from zero.

What Form Accessibility Actually Requires

The Web Content Accessibility Guidelines (WCAG) 2.1 define accessibility through four principles: perceivable, operable, understandable, and robust. For forms specifically, this translates into concrete technical requirements.

Every form control needs a programmatically associated label. Screen readers must announce field purposes, validation states, and error messages. Users must be able to navigate and submit forms using only a keyboard. Focus indicators must be visible. Color cannot be the only means of conveying information. Time limits must be adjustable. Error messages must identify what went wrong and how to fix it.

Meeting these requirements in a form builder is harder than meeting them in static HTML. Form.io components are rendered dynamically through JavaScript. They respond to user input, display conditional fields, handle validation, and manage multi-step wizards. Each of these behaviors creates accessibility challenges that static forms do not face.

The Accessibility Compliance Module handles these challenges at three layers: form building, form rendering, and template output.

How the Accessibility Compliance Module Works

The module modifies Form.io’s behavior at each stage of the form lifecycle.

At the renderer level, the module overrides default Form.io behavior to handle dynamic accessibility requirements. This includes announcing validation errors to screen readers when they occur, managing focus placement when form state changes, dynamically updating ARIA attributes as users interact with the form, and handling special cases like file uploads and wizard navigation where standard HTML patterns do not apply.

At the template level, Form.io provides the US Web Design System (USWDS) template, which renders components using markup and classes compatible with federal accessibility standards. The USWDS template handles proper HTML structure, including associated labels for every field. It applies ARIA attributes like aria-describedby and aria-labelledby where appropriate. It provides additional instructions for screen reader users, such as announcing number input types. And it ensures WCAG-compliant color contrast ratios.

Components That Meet Accessibility Standards

Form.io tests each component for accessibility compliance in standalone applications. The following components have met WCAG 2.1 AA accessibility standards during testing and can be used to create fully accessible forms:

Basic input types work well: text fields, text areas, number inputs, password fields, and email fields. Selection components including checkboxes, radio buttons, and select dropdowns are compliant when properly labeled. Date and time components work with the module, though the combined Date/Time picker requires both the USWDS template and the VPAT module for full accessibility.

Layout components including panels, columns, and field sets are accessible. The form wizard component works when configured with the Classic header style rather than the Vertical header.

Components That Do Not Meet Accessibility Standards

Some Form.io components present elements or functionality that do not comply with accessibility standards. Using these components may create accessibility limitations in your form or application.

The module excludes components that rely on visual interaction patterns that cannot be replicated for screen reader users, components that trap keyboard focus, and components that convey information through color or position alone. If you need accessibility compliance, do not use components outside the approved set, even if you believe you can configure them accessibly.

This is a critical point: using an approved component incorrectly can still create accessibility problems. Each component requires proper configuration, including complete labels, descriptions, and relevant field settings.

USWDS Template and Federal Compliance

The US Web Design System is a collection of standardized UI components and visual styles developed by the General Services Administration to help developers deliver accessible web applications for government use. Form.io’s USWDS template renders forms using USWDS-compatible markup.

For applications that must meet Section 508 requirements, this matters because USWDS components have been evaluated against federal accessibility standards. The USWDS template produces HTML that integrates properly with the design system’s accessibility features. Organizations building forms for federal agencies or federal contractors can use Form.io with the USWDS template as part of their compliance strategy.

The template handles accessibility-related markup automatically:

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/uswds/3.1.0/css/uswds.min.css">
<link rel="stylesheet" href="https://cdn.form.io/uswds/uswds.min.css">
<script src="https://cdnjs.cloudflare.com/ajax/libs/uswds/3.1.0/js/uswds.min.js"></script>
<script src="https://cdn.form.io/uswds/uswds.min.js"></script>

The USWDS template can be used independently of the Accessibility Compliance Module. However, the full accessibility feature set requires both the template and the module working together. Features like accessible tooltips, accessible Date/Time components, and accessible modal edit windows require the combined USWDS and VPAT modules.

What the Module Does Not Do

The Accessibility Compliance Module provides tools for building accessible forms. It does not guarantee that every form you build will be accessible, and it does not make your entire application accessible.

Form design still matters. A form built with compliant components can still be inaccessible if labels are vague, instructions are missing, or error messages are unhelpful. The module gives you accessible building blocks, but you must assemble them thoughtfully.

Application context matters. An accessible form embedded in an inaccessible application does not create an accessible user experience. If your page navigation traps keyboard focus, if your surrounding content lacks proper heading structure, or if your site-wide styles break color contrast, your forms inherit those problems.

Testing is still required. The module provides components that have passed accessibility testing in isolation. Your specific form, with your specific configuration, in your specific application context, requires its own testing. Automated tools like aXe and pa11y can catch many issues, but manual testing with actual assistive technologies remains necessary for compliance verification.

The module does not provide VPAT documentation for your application. Form.io can provide information about component-level compliance, but your application’s Voluntary Product Accessibility Template must reflect your complete product, not just the form components.

Implementing Accessible Forms

To enable the Accessibility Compliance Module, configure the following environment variable in your Enterprise Server deployment:

VPAT=true

Within the Form.io Portal, you can enable the module through project settings by adding a public configuration key with key “vpat” and value “true”.

To render accessible forms in your application, import and register both the VPAT module and the USWDS template:

Formio.use(vpat);
Formio.use(uswds);
Formio.createForm(document.getElementById('formio'), 'https://[subdomain-targeting-formio-deployment].[yourdomain.com]/[stage-path]/[formname]');

The Form.io GitHub repository provides the USWDS template implementation. The VPAT module is available as part of the Accessibility Compliance Module license.

When to Use the Accessibility Compliance Module

The module makes sense when your application has explicit accessibility requirements. This includes applications for federal agencies or federal contractors subject to Section 508, applications that must demonstrate WCAG 2.1 Level AA compliance, healthcare applications subject to accessibility requirements under the ADA, and any application where accessibility failures create legal or reputational risk.

The module also makes sense when you want to reduce accessibility remediation costs. Building with accessible components from the start is significantly cheaper than retrofitting accessibility after development. The module enforces accessible patterns during form creation rather than catching problems in testing.

Connection to Other Form.io Features

Accessible forms work with other Form.io capabilities. Form validation and conditional logic function normally with accessible components, though conditional field appearance changes must be available  to screen readers, which the module handles. PDF form generation creates separate accessibility considerations for the PDF output, which the PDF Template Designer addresses.

The Accessibility Compliance Module is enabled for all tenants or none in a Multi-tenancy deployment.

Data captured through accessible forms stores identically to data from standard forms. Export capabilities and data reporting work without modification.

The Real Cost of Inaccessible Forms

Organizations often treat accessibility as a nice-to-have feature or a compliance checkbox. This underestimates both the user impact and the business risk.

Forms are interaction points. They capture applications, process transactions, and enable services. An inaccessible form excludes users from those interactions entirely. For government services, this exclusion may violate legal requirements. For commercial applications, it represents lost customers and potential liability.

Retrofitting accessibility is expensive. Discovering accessibility problems in testing or production requires rework of completed features. The Accessibility Compliance Module moves accessibility requirements to the start of form development, where they cost the least to address.

Related Resources