Websites

Forms and interactive controls encompass each principle in the Web Content Accessibility Guidelines: they must be perceivable, operable, understandable and robust.

Form Labels

Labels or instructions must be provided for form elements. Labels must be sufficiently descriptive to ensure that people filling out the form know what data is expected. Additionally, labels must be programmatically associated with their inputs for people who use screen readers. Required fields must also be conveyed in an accessible manner. Several approaches are available to form authors:

• Include an asterisk (*) in the label to indicate a field is required.
• Provide instructions that indicate which fields are required (e.g., "All fields are required.")
• Use programmatic markup to identify inputs using the required attribute.

Do not rely on color alone to indicate required fields. Using red text labels, for example, is not sufficient on its own to indicate that a field is required.

Keyboard Interaction

Ensure forms can be completed without using a mouse. Using the Tab key, navigate through the form to ensure that keyboard focus is visible and moves in a logical order. Ensure custom components like date pickers do not rely on the mouse.

Keyboard Navigation Tips

• Use Shift + Tab to navigate in reverse.
• Use the arrow keys to navigate radio buttons.
• Use the Spacebar key to toggle checkboxes.
• Activate buttons using Enter or Spacebar.

Form Validation

What happens when a user enters incorrect data in a form? What happens if required fields are not completed? When validating forms, handle errors gracefully. If an invalid value is identified, describe the error in text. If a correction can be provided, suggest it. When legal commitments, financial transactions or user-controllable data are at stake, ensure that submissions can be reversed, checked or confirmed.

Changes in Context

A change of context is a significant change that can disorient users when it's not expected. Changes in context can include opening a new browser tab, navigating to a new page, modifying content on the page or moving keyboard focus.

Merely focusing on an input should not cause a change of context. Similarly, user input should not initiate a change of context unless the user has been informed of the change. For example, tabbing to a form input or entering data in a form field should not launch a new browser window.

A change in content is not always a change in context. For example, if the user changes the value of a select box in a conditional form, the form fields that follow the select box may update dynamically, resulting in a change in content. However, modifying form questions that preceded the select box would be considered a change in context: people who are blind or low vision may not realize the preceding form elements have changed.

Changes in Content

When content changes, inform users of the change. Common examples of changes in content include:

• Launching a dialog
• Navigating between pages in a single-page application (SPA)
• A search input that automatically populates results on the page as the user types

Depending on the scenario, developers may choose different approaches to informing users of changes in content, typically through focus management or the use of the Accessible Rich Internet Applications (ARIA) specification.

Focus Management

Consider a multi-page form in a single-page application. After completing each section, the user selects a Continue button that dynamically swaps out the current page with the next page of questions. This is a perfect use case for managing focus to convey a change in content. When the new page of questions loads, programmatically set focus to the first question or a page heading. People who use screen readers will be notified of the change and people who navigate with the keyboard will resume at the top of the form.

Dialogs, like a custom date picker, are prime candidates for focus management. When the dialog launches, programmatically set focus to the dialog. When the dialog closes, return focus to the control that launched it.

In both cases, managing focus will provide notification of the change in content to people using a screen reader, as well as a logical focus order for people using the keyboard.

ARIA Live Regions

Consider a search form that automatically populates results on the page as the user types. Setting focus to the results is not feasible, as it would interrupt the user's typing. Instead, a live region can be used to convey the change in content. In this example, the author could indicate the number of search results displayed (e.g., "18 articles found") in an element with the status role, dynamically updating its contents as the user types. The results will be announced by a screen reader without interrupting the user.

Use live regions sparingly. Since content in a live region is announced by screen readers when it's updated, excessive use of live regions – or substantial changes in content – can cause an overwhelming amount of information to be announced, disrupting the user experience.

Related Success Criteria

Find more information on the related WCAG 2.1 Success Criteria in the following W3C Understanding documents.

Perceivable

• Non-text Content
• Info and Relationships
• Meaningful Sequence
• Identify Input Purpose
• Use of Color
• Contrast
• Reflow

Operable

• Keyboard
• No Keyboard Trap
• Timing Adjustable
• Focus Order
• Headings and Labels
• Focus Visible
• Label in Name

Understandable

• On Focus
• On Input
• Consistent Identification
• Error Identification
• Labels or Instructions
• Error Suggestion
• Error Prevention

Robust

• Name, Role, Value
• Status Messages