Best Practice Guide for Making Forms Accessible - Conforming to WCAG, level AA

Accessible forms conform to level AA, as per the standard defined in WCAG 2.1. Most organizations strive to meet this level, and it is also the minimum legislated level for the public sector.

InRule AB strives to make its entire platform as closely aligned to WCAG as possible. This best practice guide has been developed in conjunction with the Voluntary Product Accessibility Statement as a tool to make InRule Process Automation forms conformant according to the WCAG standard. The forms created are not compliant with WCAG level AA by default. However, they can be made conformant to the standard under certain circumstances.

This document outlines principles for designing forms and gives 13 concrete best practice guidelines for configuring forms. It provides recommendations on which tools to use to test WCAG conformance.

Under what circumstances can forms be accessible?

Out of the box, InRule Process Automation forms are not compliant with WCAG. A number of considerations must be made, and CSS must be added to the form.

General principles:

• Forms should be short and simple to use – use a script task to copy data to a bigger form if the form needs to grow later in the process.
• Keep forms simple – it should be possible to view all fields when rendering the form. Don’t hide instructions behind hover symbols or in collapsible panels. Don’t show/hide sections based on previous selections. Make it easy to correct mistakes.
• Forms should be empty when rendered – avoid populating fields with data, as this is harder for the text-to-speech tool to interpret.
• Forms should be symmetric  - try to make the fields similar in size, even though some fields require less information than others.
• Make it possible to correct mistakes - If applicable, enable the user to go back and correct a form through a feedback loop.

WCAG’s four design principles for the form builder

There are four principles under WCAG that should be followed when creating the form: it should be perceivable, operable, understandable and robust.

Perceivable

The information and the form’s constituent parts should be presented to users in ways they can perceive them – for example, text that is easily interpreted by a text-to-speech tool, or by using colors and formatting that is high enough contrast that it can be understood by users with color blindness.

Operable

The interface and navigation should be operable independent of tools. For example, it should be possible to navigate and submit the form through keyboard actions only. The forms should not be timed or require pausing.

Understandable

Forms should be easily readable and understandable. This means avoiding abbreviations and unusual words. The context should not change on focus or on input and navigation should be consistent.

Robust

Finally, the form should be robust. It should be interpretable by a wide variety of users and assistive technologies and it should be easy to correct mistakes.

Guidelines surrounding style, formatting, and contrast

Below is the first set of guidelines for configuring WCAG conformant forms. All guidelines must be followed in order to conform. If an exception must be made, the customer should be informed about its negative impact on WCAG conformance.

• Add a language tag to the form 
  In order for a text-to-speech tool to be able to read the form, set the HTML language tag in Forms, so that the text-to-speech tool knows which language to read in. 
  
  
• Form fields should have fieldLabel and emptyText
  Most text-to-speech tools will interpret and read out websites from the top left to the bottom right. The field attributes fieldLabel and emptyText should be populated on all form fields.
  
  
• Use high contrast in text and buttons
  Contrasts should be at least 4.5:1 on fields, buttons, and other graphical representations.
  In your CSS stylesheet, ensure the contrast in emptyText and other attributes is high enough. Update emptyText to #737373 instead of Grey.
  
  
• Colors/visual objects should not be part of the instructions
  To ensure that an object is perceivable, avoid using colors or visual objects. For example, do not write “Click the button on the right” and do not indicate that a field is mandatory by making it red.
  Do not hide hyperlinks behind text, like this. Instead, write out the location of the hyperlink as the text like this: www.live.barium.se
  
  
• It should be possible to use the keyboard to navigate the webpage
  Make tabbing explicit by defining the attribute called tabIndex for each form field. Do not forget to test this extensively before deploying.
  It should be possible to submit the form by using the keyboard. 
  
  
• Build for mobile
  Some users may require the website to be zoomable/enlarged. Therefore, build the form with a CSS which contains the formatting for mobile devices, even if you suspect most users will not use a mobile device to access the form.
  
  
• Images/Logos should be tagged with alternative text
  To make it possible for the text-to-speech tool to interpret the image, use caption text on images. This includes logos. Do not insert critical information in images or use images to show text.

Guidelines for managing user interactions and errors

• Mandatory fields should be stated explicitly
  If allowBlank = False, or if there is a rule/listener that makes a field mandatory, add a text panel close to the field stating that it is mandatory. The text panel may show from the start, or upon attempting to submit the form.
  
  
• Do not use events “blur” or “change” to format fields
  For example, do not add a prefix or suffix that is populated when the cursor leaves the form field.
  
  
• Do not hide/show sections
  All fields should be shown on render, including instructions panels.
  Do not hide/show sections based on user selections, as this makes it hard to correct mistakes.
  
  
• All list values should be visible when the list is expanded
  A text-to-speech tool will not be able to read out many list values. Therefore avoid large lists that require scrolling. Avoid using emojis and abbreviations in list values.
  
  
• Do not use filters or automatically populate values in value lists
  Do not use lists to filter other values in other lists. The user should easily be able to see all options in lists. If a parent/child filter is used on lists, it is no longer considered accessible.
  Do not use value lists that populate other fields through the attribute called valueFrom.
  
  
• Do not use visual cues outside the focus area
  For example, using panels in the top right corner to display a message is not considered accessible. Often, users may zoom in or use a digital magnifying glass, in which case they may not see visual cues outside of their area of focus.
  Do not use deadlines on external tasks because their visual cue is outside the form.
  
  
• Confirm submission – use a check button or a JavaScript popup
  A form may not be “done” until the user has been able to go back and review all fields. Therefore, to prevent the user from submitting the form by mistake, implement a mandatory check box at the bottom that the user checks before submitting. Alternatively, user a JavaScript pop-up where the user must confirm submission again. The pop-up must have two options, one for submission and one for canceling the submission.  

Supported accessibility tools

InRule will only guarantee WCAG conformance with Process Automation forms with the following aid tools:

• Text-to-speech tool: Narrator (built-in Windows 11)
• Screen magnifying tool: Magnifier (built-in Windows 11)

InRule recommends that developers use a plug-in to test that the form is WCAG conformant: Use Wave by WebAIM