Form Labels, Validation, and Directions

Web Accessibility Micro Course: Form Labels, Validation, and Directions

To instruct users on how to complete a form, it must first be accessible to them. This is a straightforward process involving a few key aspects:

• Input group labels.
• Input form labels.
• Prevention of errors.
• Considerations and directions, where applicable.
• Form validation.

For each one these components, information needs to be displayed. This data must be correct and relevant, programmatically recognizable, and programmatically connected to a specific form group or element.

The more input a form or element requires, the more time one must allocate to accessibility. Specifics to be mindful of include:

• Updating and establishing ARIA values, roles and titles, where applicable.
• Focus management.
• Real-time ARIA announcements, where applicable.

Labels

Semantic Labels

• Labels need to be programmatically-recognizable.
• Labels need to be programmatically connected with their matching elements.

Descriptive Label Text

• Labels need to be descriptive.
• Labels cannot depend strictly on aspects of sensory references.

Icon Labels

• Icons can be utilized as visual labels (minus visual wording) if the icon’s meaning is perceivably self-explainable; as well as where programmatically-connected semantic labels are assistive technology-accessible.

Placeholder Text Labels

• Placeholder text cannot be utilized as the sole method of labeling for text wording.

Label Visibility

• Labels need to be easily apparent.

The closeness of Controls to Labels

• In the DOM, a label should appear beside its matching element.
• A label should be perceivably beside its matching element.

Numerous Labels for a Single Field

• When various labels are used for a single element, each one needs to be connected programmatically with its matching element.

Single Labels for Numerous Fields

• When a single label is utilized for numerous elements, it needs to be connected programmatically with each of its matching elements.

Labels for Groups

Semantic Group Labels

• Group labels need to be programmatically recognizable.
• Group labels need to be connected programmatically with the group if individual labels for each element are not enough by themselves.

Descriptive Group Labels

• Group labels need to be descriptive.
• Group labels cannot only rely on aspects of sensory references.

The closeness of Group Labels

• Group labels should be displayed beside collected elements.
• Group labels should be beside collected elements in the DOM.

Group Labels Visibility

• Group labels should be visible.

Directions and More Relevant Details

Section, Group, and Form Directions

• Directions for sections or groups need to be programmatically recognizable.
• Directions for sections or groups should be programmatically connected to the group.
• Directions for sections or groups need to be visible.
• Directions for sections or groups need to be descriptive.
• Directions for sections or groups should be beside collected elements in the DOM.
• Directions for sections or groups should be displayed beside collected elements.
• If the directions for sections or groups are not vital, they do not have to be displayed until a user requests to see them.
• Directions for sections or groups should not exclusively depend on aspects of sensory references.

Input Directions

• Element directions need to be accessible as programmatically recognizable text.
• Element directions need to be programmatically connected to the element.
• Element directions need to be visible.
• Element directions need to be descriptive.
• Element directions should be beside the element in the DOM.
• Element directions should be perceivably beside the element.
• Element directions should not depend exclusively on aspects of sensory references.
• If element directions aren’t vital, they do not have to be displayed until users ask to see them.

Mandatory Fields

• Mandatory fields should be assigned as such programmatically.
• Mandatory fields should be labeled as a required field.
• The process of validating a form needs to display an error message telling the user that the field is mandatory if the field isn’t classified as essential both programmatically and perceivably in the form’s original state.

 

Custom Widgets and Dynamic Forms

Context Changes

• Concentrating on an element cannot automatically activate a context change. Exceptions are made if the user has been told in advance of such changes.
• Modifying the value of an element cannot automatically activate a context change. Exceptions are made if the user has been told in advance of such changes.
• Using a mouse to hover over an element cannot automatically activate a context change. Exceptions are made if the user has been told in advance of such changes.

Inputs for Custom Forms

• Wherever feasible, custom form elements should behave like native HTML form elements as much as possible.
• When feasible, native HTML form elements should be utilized.
• State changes and updates that can’t be articulated through ARIA or HTML means should be conveyed through real-time ARIA messages.
• Custom form elements should have relevant values, roles, and titles.

Form Validation

Considerations for Error Identification

• Error input needs to be programmatically connected to the relevant element.
• Error input should be made accessible immediately after a form is submitted (or after a similar event in the absence of a form submission).
• Error input needs to be descriptive.
• Error input needs to be programmatically recognizable.
• Error input needs to be displayed.

Considerations for Confirmation of Successful Input

• Confirmation of successful input should be descriptive.
• Confirmation of successful input should be programmatically recognizable.
• Confirmation of successful input needs to be displayed.