Accessibility Compliance Module
Last updated
Was this helpful?
Last updated
Was this helpful?
Forms necessarily require a degree of end-user interaction, which highlights the need to make that interaction accessible. Applications that require compliance with various accessibility standards and guidelines must be thoughtful about the design of the forms and the way those forms are presented within the application. Simply using form components rated to be compliant with accessibility standards does not ensure that the whole form is compliant. Further, an accessible form does not necessarily mean that the broader application is accessible. Application developers must evaluate the finished product holistically.
Form.io offers a variety of tools and best practices through the entire platform to support developers in implementing accessible applications.
There are many standards used to evaluate the accessibility of an application. One of the most common standards is the , published by the World Wide Web Consortium (W3C). The current standard is WCAG 2.1.
WCAG 2.1 evaluates web accessibility based on several principles. When a Form.io component is described as being WCAG 2.1 compliant it means that component, when used according to best practices, will not interfere with a web application's WCAG 2.1 rating.
Additionally, the United States General Service Administration developed the (USWDS), a collection of standardized UI components and visual styles, to provide developers with a number of resources to aid in delivering accessible web applications and services. Form.io offers a USWDS that renders forms using markup and classes that are compatible with USWDS standards.
The first step toward implementing forms in an accessible application is building the form.
Each Form.io component is evaluated for accessibility compliance based on how the component is presented within a standalone application.
When building forms using the Developer Portal or the the following components met WCAG 2.1 accessibility standard during testing, and may be used to create fully accessible forms:
Text Field
HTML
Hidden
Data Source
Text Area
URL
Content
Container
File
Number
Phone Number
Columns
Review Page
Password
Date & Time
Field Set
Checkbox
Day
Panel
Select Box
Time
Table
Select
Currency
Well
Radio
Button
Using these components to create an accessible form may require configuring the component settings and parameters in a specific way. Ensure all labels, descriptions, and other relevant fields are completed as required.
A selection of components may present elements or functionality that do not comply with accessibility standards. The following components are not included in the Accessibility Compliance Module, and using them may create accessibility limitations in a form or application:
Tags
Tabs
Data Map
CAPTCHA
Address
Data Grid
Nested Form
Survey
Edit Grid
Sketchpad
DataTable
Tagpad
Signature
Custom
The Form.io Accessibility Module alters the functionality of Forms, as well as the Form.io Platform, in several ways. The Accessibility Module:
Provides overrides for the formio.js renderer.
Limits components in the Developer Portal Form Builder to avoid components with limited accessibility.
Includes Form Builder markup overrides in order to make the builder accessible (keyboard accessibility, accessible drag-n-drop functionality, additional screen reader announcements upon user actions).
Handles dynamic changes on the form and during building a form.
To enable the Accessibility Compliance Module, the following environment variable must be configured in the Enterprise Server as part of the deployed environment:
VPAT=true
Additionally, the module must be imported and registered, as seen in the following snippet:
Once the Form Builder defines the form with accessible features, it is up to the Form Renderer to present the form within the application in an accessible way.
The role of the form renderer includes the following accessibility-related functions:
Screen readers' announcements upon user action
Focus order/Focus trap/Focus placement
Dynamic change of aria-attributes
Validation messages handling
Special styles for invalid/valid fields
The role of the template includes the following accessibility-related functions:
Proper HTML markup (every form field needs an associated label, correct component structure etc.)
Aria-attributes such as aria-describedby, aria-labelledby, etc.
Additional helpful messages for sighted users
Additional instructions for non-sighted users (e.g. number types, etc.)
WCAG compliant color contrasts (only applicable for USWDS for now)
When using the USWDS template, it must be imported and registered to be used within the application, similar to the following:
The USWDS template does not require the Accessibility Module. Likewise, the Accessibility Module does not necessitate using the USWDS template for all forms. Some features, however, require the use of both the Accessibility Module and the USWDS template. Such features include:
Accessible tooltips.
Accessible Date/Time component.
Ability to use accessible “Modal Edit” windows for components when being filled in by end users.
Accessible forms are used just like any other form, with the additional steps of importing the necessary module and any required templates.
To embed the “https://examples.form.io/example” directly to a website the following code would be used:
Displaying a form as a Wizard, it is an accessibility best practice to ensure the set the Wizard Header to Classic. Using a Vertical header/step indicator may require significant customization to meet accessibility standards.
Templates control how Form.io renders each component into a visual and functional element in the form user's browser. The default template uses Bootstrap to control the look and functionality of each component. Form.io also provides a to render components in an accessible way.