Interactive Forms

Owned by Christina Lutz-Hatfield
Last updated: Sept 30, 2024
16 min read

 

Table of Contents

Overview

Form elements need to be accessible to both screen reader and keyboard users.

Screen reader users and keyboard only users typically navigate forms by using the TAB key on the keyboard, to jump from form control to form control.

In order for those users to be able to properly navigate forms, the proper code and markup needs to be incorporated.

Ensure that the purpose of a form input collecting information about the user can be programmatically determined, so that user agents can extract and present this purpose to users using different modalities. The ability to programmatically declare the specific kind of data expected in a particular field makes filling out forms easier, especially for people with certain cognitive disabilities.

Forms can be visually and cognitively complex and challenging to use. Accessible forms are easier to use for everyone, including people with disabilities.

  • People with cognitive disabilities can better understand the form and how to complete it, as making forms accessible improves the layout structure, instructions, and feedback.

  • People using speech input can use the labels via voice commands to activate controls and move the focus to the fields that they have to complete.

  • People with limited dexterity benefit from large clickable areas that include the labels, especially for smaller controls, such as radio buttons and checkboxes.

  • People using screen readers can identify and understand form controls more easily because they are associated with labels, field sets, and other structural elements.

Step by Step Forms Guide

Please see our step by step forms guide on how to incorporate accessible forms from a code and design perspective.

Forms Guide - Step by Step Guidelines on How to Incorporate Accessible Form Elements

Forms Checklist

 

  • Notify users when form elements are required to complete.

  • Create a logical structure and tab order within forms.

  • Ensure that form related instructions do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.

  • Ensure that the purpose of a form input collecting information about the user can be programmatically determined, so that user agents can extract and present that information to the user without having them type in the info (autocomplete).

  • Ensure that form related alert and error messaging do not only rely on color to convey the information.

  • Ensure that keyboard only users and screen reader users who rely on using a keyboard are able to navigate, complete and submit forms.

  • Ensure that content does not "trap" keyboard focus within subsections of content on a Web page. For example when navigating to and away from a calendar widget/component.

  • Provide users with adequate time to complete and submit forms. View more details.

  • Provide users with adequate time to correct form related error messages. View more details.

  • Provide sighted keyboard only users with a keyboard focus indicator to let them know which form element has keyboard focus. The keyboard focus indicator needs to provide adequate color contrast between foreground and background.

  • Ensure that entering data or selecting a form control has predictable effects.

  • Ensure that form components that have the same functionality within a set of web pages are identified consistently.

  • Provide users with a mechanism to initiate a change in form behavior and form submissions.

  • Make users aware of important changes in content that are not given focus, such as inline error messages.

  • Provide role, state and value information in connection with form elements in order to make functionality accessible to assistive technology.

  • Ensure that visual information required to identify user interface components should have a contrast ratio of at least 3:1 against adjacent color(s).

Associate Labels Explicitly with Their Form Controls

 

The <label> element is used to associate a text label to a form control. This allows a screen reader to read the associated label text when the user navigates to the form control.

  • All form controls need to include an “id” that associates the form control with the respective form label. 

  • The “id” attribute needs to match the “for” attribute in the form label.

Example:

<label for=”name” class="control-label">Name</label> <input placeholder="" id="name" formtype="c02" name="name" type="text">

 

Group Lists of Form Controls

 

  • Group lists of form controls when there are multiple options to elect from

  • Group the list of options with a “fieldset” 

  • Use a “legend” to describe the list of form control options.

  • Use checkboxes instead of radio buttons when more than one option can be selected

  • User should be able to select text labels

Please see example below.

<fieldset> <legend>Name</legend> <input id=”equityapplicant” type="checkbox" name="authorization" value="equityapplicant"> <label for="equityapplicant"> I am an Equity Applicant </label><br/> <input id=”equityincubator” type="checkbox" name="authorization" value="equityincubator"> <label for="equityincubator"> My business is an Equity Incubator</label><br/> <input id=”signedaffidavit” type="checkbox" name="authorization" value="signedaffidavit"> <label for=”signedaffidavit”> I registered my business with the Office of Cannabis and have signed an affidavit</label><br/> <input id=”temporarypermit” type="checkbox" name="authorization" value=”temporarypermit”> <label for=”temporarypermit”>I have a temporary cannabis permit</label><br/> </fieldset>

Add a Title Attribute to Form Controls with No Labels

 

The preferred way is to include a form label with each form controls. However, if this is not possible use the title attribute to label form controls when the visual design cannot accommodate the label (for example, if there is no text on the screen that can be identified as a label) or where it might be confusing to display a label. User agents, including assistive technology, can speak the title attribute.

<input class="form-control" title=”Search Regulations” placeholder="Search regulations" name="q" type="text">

Required Form Controls

Notify screen reader users when form elements are required to complete.

Include the word ‘required’ or aria-required=”true' in the form element to indicate mandatory form fields for screen reader users. 

Providing HTML5 Required Attribute

If this attribute is used on any form field, it is identified as required by assistive technologies.

Example: 

  • Note: adding the required attribute to the input will trigger the browser's built-in validation features, and will prevent form submission if the field is empty. If you are using some other form of error prevention, you may want to suppress the browser's built-in validation by using the novalidate attribute.

Providing Aria-Required Attribute

Similar to the “required” attribute in HTML5, WAI-ARIA introduced the “aria-required” attribute. If this attribute is used on a form control it will be exposed as required by assistive technologies.

No validation or "enforcement" mechanism comes along with this attribute, and it has no visual impact.

Example: 

Let Screen Reader Users Know When Radio Buttons are Required to Complete

Add the aria-required attribute in combination with the radiogroup role in the fieldset tag.

This works with a group of radio buttons, but not with a group of checkboxes.

Example: 

 

Let Screen Reader Users Know When a Group of Checkboxes are Required to Complete

Add an invisible required label that will be announced by the screen reader. A sighted user will not see this text.

Example:

 

Let Screen Reader Users Know When Standalone/Single Checkboxes are Required to Check

You can make standalone/single checkboxes required by using the aria-required="true" and required attributes.

Then add the role=”checkbox” to the single checkbox.

Example:

 

Form Instructions and Help Text

Place Important Form Instructions and Help Text in a Logical Reading Order for Screen Reader Users and Associate Them with Specific Fields Using ARIA

If you place the form instructions above the form control screen reader users will be provided with critical information before the form control receives keyboard focus.

Also, screen reader users sometimes navigate forms using the Tab key to jump from form control to form control in which case they would skip the form instructions. 

To cover this scenario you can use the “aria-describedby” attribute to associate the form instructions with the form control.

Example:

Accessible Autocomplete Forms

Screen-reader Interactions

  • When the form field gains focus: 

    •  Tell screen reader users that the input field is an auto-suggest.

    •  Tell screen reader users they can select from the suggestion list or type their own input.

    • Tell screen reader users the number of suggestions that are available

  • Allow screen reader users to scroll through the list of suggestions by using the arrow keys.

  • When suggestions are arrowed through they are spoken aloud.


Add role=”combobox” to the <input> field to tell screen reader users that the input field is an auto-suggest.

  • Default text is “Edit Combo”

Add aria-autocomplete=”both” to the <input> field to tell screen reader users they can select from the suggestion list or type their own input. 

  • This is the default text: “To set the value use the arrow keys or type the value”

  • You can customize this text by using the aria-describedby="initInstr"

  • Screen reader users can’t use the arrow keys until the autocomplete starts. 

  • You may want to use a more customized message such as “When autocomplete results are available use up and down arrows to review and enter to select.”

Add aria-live=”assertive” to announce the number of results available. The content of the <div>, which isn’t visible on screen, updates every time the list length changes.

Add aria-owns to the <input> field to link the suggestion list to the input field.

Add role=“listbox“ to the suggestion list <div> to tell screen reader users it contains a list of selectable items.

Add aria-activedescendant to the <input> element and populate it with the id of the currently highlighted list item. The aria-activedescendant value changes as the user presses the Up and Down arrows.

Add role=“option“ to each suggestion item, along with a unique id. That id is used by the aria-activedescendant attribute of the <input> element, whose value changes as users move through the list items with the arrow keys.

Add aria-expanded=”true” to indicate that the popup list is displayed.

Code Example

Here is an example of what the code would look like

https://codepen.io/ademcifcioglu/pen/xdOyXv

Declaring Form Controls as Invalid

Wait to declare form controls as invalid until the form control has lost focus, or there has been an adequate delay in key presses (maybe a few seconds).

Example Default State:

<form novalidate>

<label for="name"> Name:</label>

<input id="name" required aria-invalid="false">

</form>

Example Invalid Error Message State:

<form novalidate>

<label for="name">  Name:</label>

<input id="name" required aria-describedby="name_msg" aria-invalid="true">

<span id="name_msg">Please enter your name.</span>

</form>

Code Example: https://codepen.io/TPG/pen/3b68c22db120c0960503fe892bb2c068

Error, Alert and Status Messaging Within Forms

Ensure that users are aware that an error has occurred when submitting a form and can determine what is wrong.

Ensure that users receive appropriate suggestions on how to correct a form input error.

Provide appropriate suggestions on how to correct a form input error.

Error prevention related to legal and financial data: Help users with disabilities avoid serious consequences as the result of a mistake when performing an action that cannot be reversed.

Make users aware of important changes in content.

Let assistive technology notify users about status changes that don't take focus

Please see the Alert and Error Message Guidelines for more details on how to comply with these guideline.

Accessible Calendar Widget

As a keyboard user I should be able to Interact with a calendar widget.

As a keyboard user I should be able to use the tab key to access the calendar widget as well as navigate through the months and years.

I should also be able to use the arrow keys to navigate between dates. 

Here is an example of a fully accessible calendar widget. 

See Code Example Here:

https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html  

Accessible Multiselect Combobox Dropdown Menus

As a keyboard user and screen reader user I should be able to delete selected items within a multiselect combobox dropdown menu.

As a keyboard only and screen reader user,  I should be able to use the shift+tab keys to tab backwards to a button/label and then press the spacebar (or enter key) to remove/delete that item.

Here I’m referring to the buttons that appear once you have made a selection.

Within this article https://www.24a11y.com/2019/select-your-poison-part-2/ , 

there is a codepen multiselect combobox example that places the selected buttons above the form control.

This example allows me to use the shift+tab keys to navigate back to all buttons and use the spacebar or enter key to delete them, not just the last button. 

In this example the screen reader will also make an announcement to press the spacebar to delete an item. 

Accessible Placeholder Tags in Form Controls

Avoid using dashes, parentheses and other characters in placeholder tags in form controls

As a screen reader user I should NOT be provided with dashes in a placeholder tag to enter for example a phone number.

For example when entering phone number.

When the form control receives keyboard focus the screen reader will announce the dashes as follows “underline underline underline underline underline underline type of text”.

Incorrect Way:

<input value="" spellcheck="true" inputmode="decimal" lang="en" class="form-control" type="text" name="data[phoneNumber]" required="" id="input-ebt1nqd" ref="input" placeholder="___-___-____" aria-invalid="false">

 

Correct Way:

<input value="" spellcheck="true" inputmode="decimal" lang="en" class="form-control" type="text" name="data[phoneNumber]" required="" id="input-ebt1nqd" ref="input" aria-invalid="false">

 

Identify Input Purpose

Use code to indicate the purpose of common inputs, where technology allows.

Some people with cognitive disabilities may not understand the input's purpose from the label alone.

Ensure that the purpose of a form input collecting information about the user can be programmatically determined, so that user agents can extract and present this purpose to users using different modalities.

The ability to programmatically declare the specific kind of data expected in a particular field makes filling out forms easier, especially for people with certain cognitive disabilities.

Please see more detailed information on identifying input purpose.

Provide Users with Adequate Time to Submit and Complete Forms

People with disabilities may need more time to complete activities.

Users should have adequate time to complete and submit forms.

Allow users to turn off, adjust, or extend any time limits.

For each time limit that is set by the content, at least one of the following should apply:

Turn off

The user is allowed to turn off the time limit before encountering it; or

Adjust

The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or

Extend

The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or

Real-time Exception

The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or

Essential Exception

The time limit is essential and extending it would invalidate the activity; or

20 Hour Exception

The time limit is longer than 20 hours.

Please see more detailed information on how to comply with this standard.

Provide Consistent Identification

Identify repeating functions consistently.

Consistently identified actions are especially important to people with disabilities.

Components that have the same functionality within a set of web pages should be identified consistently.

Screen reader users rely heavily on their familiarity with functions that may appear on different web pages.

If identical functions have different labels on different web pages, the site will be considerably more difficult to use. It may also be confusing and increase the cognitive load for people with cognitive limitations.

This consistency extends to the text alternatives. If icons or other non-text items have the same functionality, then their text alternatives should be consistent as well.

If there are two components on a web page that both have the same functionality as a component on another page in a set of web pages, then all 3 must be consistent. Hence the two on the same page will be consistent.

Please see more detailed information on how to comply with this guideline.

Make it Easy for Users to Complete Multi-Step Forms and Processes

Don't ask for the same information twice in the same session.

Some people with cognitive disabilities have difficulty remembering what they entered before.

Information previously entered by or provided to the user that is required to be entered again in the same process is either:

  • auto-populated, or

  • available for the user to select

Ensure that users can successfully complete multi-step processes. It reduces cognitive effort where information is asked for more than once during a process. It also reduces the need to recall information provided in a previous step.

Information that is required to be remembered for input can pose a significant barrier to users with cognitive or memory difficulties. All users experience a natural gradual mental fatigue as they proceed through steps in a process. This fatigue is accelerated by the stress of recalling information from short-term working memory. Users with learning, and cognitive disabilities are highly susceptible to mental fatigue.

Requiring people to recall information previously entered can cause them to give up or re-enter the same information incorrectly.

The autocomplete feature of browsers is not considered sufficient because it is the content (the web site) that needs to provide the stored information for a redundant entry, or avoid asking for the same information again.

Provide Sufficient Color Contrast in Order to Identify User Interface Components

Ensure that visual information required to identify user interface components have a contrast ratio of at least 3:1 against adjacent color(s).

The visual presentation of the following should have a contrast ratio of at least 3:1 against adjacent color(s):

  • User Interface Components

    Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

  • Graphical Objects

    Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Ensure that active user interface components/controls and meaningful graphics are distinguishable by people with moderately low vision.

Low contrast controls are more difficult to perceive, and may be completely missed by people with a visual impairment. Similarly, if a graphic is needed to understand the content or functionality of the webpage then it should be perceivable by people with low vision or other impairments without the need for contrast-enhancing assistive technology.

Please see more detailed information on how to comply with this guideline.

Provide Name, Role, State, and Value Information

Provide name, role, state, and value information on all user interface components. This enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by people with disabilities.

Ensure that Assistive Technologies (AT) can gather information about, activate (or set) and keep up to date on the status of user interface controls in the content.

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Please see more detailed information on how to comply with this guideline.

Ensure that Form Components Don’t Automatically Trigger a Change of Context

Ensure that functionality is predictable as users navigate their way through form elements.

Any form element that is able to trigger an event when it receives focus must not change the context.

For example forms submitted automatically when a component receives keyboard focus.

This helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a change of context will occur unexpectedly.

Please see more detailed information on how to comply with this guideline.

Ensure that Entering Data or Selecting a Form Control Has Predictable Effects

Changing the setting of any user interface component should not automatically cause a change of context unless the user has been advised of the behavior before using the component.

Changing the setting of any user interface component is changing some aspect in the control that will persist when the user is no longer interacting with it.

So checking a checkbox, entering text into a text field, or changing the selected option in a list control changes its setting, but activating a link or a button does not.

Changes in context can confuse users who do not easily perceive the change or are easily distracted by changes.

Changes of context are appropriate only when it is clear that such a change will happen in response to the user's action.

How This Helps Users

  • This helps users with disabilities by making interactive content more predictable. Unexpected changes of context can be so disorienting for users with visual disabilities or cognitive limitations that they are unable to use the content.

  • Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site. For example:

    • Individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected.

  • Some individuals with low vision, with reading and intellectual disabilities, and others who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.

Please see more detailed information on how to comply with this guideline.

Present Clear Instructions or Form Labels that Identify the Controls

Present instructions or labels that identify the controls in a form so that users know what input data is expected. In the case of radio buttons, checkboxes, comboboxes, or similar controls that provide users with options, each option must have an appropriate label so that users know what they are actually selecting.

Instructions or labels may also specify data formats for data entry fields, especially if they are out of the customary formats or if there are specific rules for correct input.

Content authors may also choose to make such instructions available to users only when the individual control has focus especially when instructions are long and verbose.

Do not clutter the page with unnecessary information but provide important cues and instructions that will benefit people with disabilities. Too much information or instruction can be just as harmful as too little. The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation.

Please see more detailed information on how to comply with this guideline.

Accessible Password Reveal

Changing the setting of any user interface component should not automatically cause a change of context unless the user has been advised of the behavior before using the component.

This also applies to password reveal functions for screen reader users.

The important thing to keep in mind here from a screen reader perspective is that we don't want the password to be announced when the show password button receives keyboard focus for the following reasons:

  • The screen reader user might be in a public place and don't want the password to be heard by other people. So this becomes a security issue.

  • A change in content should be initiated by the user with proper notification before the actual change takes place.

 

EXAMPLE ONE OF ACCESSIBLE PASSWORD REVEAL TOGGLE BUTTON

Here is an example of a show/hide password toggle button from Codepen that is fully accessible to screen reader and keyboard only users.

View UI and Code Example on Codepen.

I have tested this example using the JAWS screen reader.

When the password toggle button receives keyboard focus it will make the following announcement: “Show password toggle button not pressed. To toggle the state press spacebar”

When the password toggle button is activated the screen reader will make the following announcement: “Toggle button pressed. Show password. Your password is shown.”

The screen reader user can then use the shift+tab keys to navigate back to the form input field. When the form input field receives keyboard focus the screen reader will announce the password entered.

 

EXAMPLE TWO OF ACCESSIBLE PASSWORD REVEAL TOGGLE BUTTON

Here is another example of a show/hide password toggle button from the UK.gov website that is accessible to screen reader users.

View UI and Code Example on UK Site.

I have also tested this example using the JAWS screen reader.

When the password toggle button receives keyboard focus it will make the following announcement: “Show password button. To activate press enter.”

When the password toggle button is activated the screen reader will make the following announcement: “Hide password. Your password is visible.”

The screen reader user can then use the shift+tab keys to navigate back to the form input field. When the form input field receives keyboard focus the screen reader will announce the password entered.

 

WCAG Related Guidelines

1.3.1 Info and Relationships (Level A)

1.3.3 Sensory Characteristics (Level A)

1.3.5 Identify Input Purpose (Level AA)

1.4.11 Non-text Contrast (Level AA)

2.2.1 Timing Adjustable (Level A)

3.2.1 On Focus (Level A)

3.2.2 On Input (Level A)

3.2.4 Consistent Identification (Level AA)

3.3.1 Error Identification (Level A)

3.3.2 Label or Instructions (Level A)

3.3.3 Error Suggestions (Level AA)

4.1.2 Name, Role, Value (Level A)

4.1.3 Status Messages (Level AA)