Introduction

Why special attention to forms is important?

In order for users to know how to fill out a form, the form has to be accessible. For the most part this is easy to do. Key concepts include:

  • Labels for form inputs
  • Labels for groups of inputs
  • Instructions and hints, where necessary
  • Error prevention
  • Form validation

With all of these, information must be visible on the screen, accurate and meaningful, programmatically discernible, and programmatically associated with the appropriate form element or group.

Summary

The more interactive a form element or process is, the more attention needs to be given to accessibility with respect to:

  • Focus management
  • Setting and updating ARIA names, roles, and values, where necessary
  • ARIA live announcements, where necessary

Inputs

Checklist - Deque

Introduction category

None documented

Download Summary & Checklist

Tips & Tricks

Input - abstract role

Subclass Roles:

Select - abstract role

Subclass Roles:

Special Input Attributes

  • HTML5 required attribute VS aria-required
  • disabled attribute
  • readonly attribute
  • HTML5 placeholder attribute
  • aria-invalid attribute

Jump to:

Guidelines

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Labels

Checklist - Deque

Semantic Labels

  • Labels MUST be programmatically associated with their corresponding elements.
  • Labels MUST be programmatically-discernible.

Meaningful Label Text

  • Labels MUST be meaningful.
  • Labels MUST NOT rely solely on references to sensory characteristics.

Icons as Labels

  • Icons MAY be used as visual labels (without visual text) if the meaning of the icon is visually self-evident AND if there is a programmatically-associated semantic label available to assistive technologies.

Placeholder Text as Labels

  • Placeholder text MUST NOT be used as the only method of providing a label for a text input.

Visibility of Labels

  • Labels MUST be visible.

Proximity of Labels to Controls

  • A label SHOULD be visually adjacent its corresponding element.
  • A label SHOULD be adjacent in the DOM to its corresponding element.

Multiple Labels for One Field

  • When multiple labels are used for one element, each label MUST be programmatically associated with the corresponding element.

One Label for Multiple Fields

  • When one label is used for multiple elements, the label MUST be programmatically associated with each of the corresponding elements.

Download Summary & Checklist

Tips & Tricks

Simple Labels

  • Explicit Labels
  • Make implicit <label> also explicit!
  • Give Every Form Input a Label
  • Labels for Radio Buttons and Checkboxes
    • <fieldset> and <legend>
    • Radiogroup - ARIA
  • Labels for Select Lists
    • Use subgroups / optgroup for long lists
  • Labels for Buttons
    • Always try to use self-labeling via child text node
    • Informative icons needs text alternative
    • Use aria-label="" or aria-labelledby="" if the default doesn't provide a proper accessible name

Complex Form Labels

  • aria-label="" VS aria-labelledby=""
  • Don't use <placeholder> Text for a Label
  • Use a <legend> for Multiple Fields with Only One Visible <label>

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Group Labels

Checklist - Deque

Semantic Group Labels

  • Group labels MUST be programmatically-associated with the group if the individual labels for each element in the group are insufficient on their own.
  • Group labels MUST be programmatically-discernible.

Meaningful Group Labels

  • Group labels MUST be meaningful.
  • Group labels MUST NOT rely solely on references to sensory characteristics.

Proximity of Group Labels

  • Group labels SHOULD be visually adjacent to the grouped elements.
  • Group labels SHOULD be adjacent in the DOM to the grouped elements.

Visibility of Group Labels

  • Group labels MUST be visible.

Download Summary & Checklist

Tips & Tricks

Groups of Form Labels

  • Group Related Form Elements
  • <legend> need to be the first child element of the <fieldset>
  • Nested <fieldset> / <legend> will not work well on all screen readers

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Instructions & Other Helpful Info

Checklist - Deque

Instructions for Forms, Groups, and Sections

  • Instructions for groups or sections SHOULD be programmatically-associated with the group.
  • Instructions for groups or sections MUST be programmatically-discernible.
  • Instructions for groups or sections MUST be meaningful.
  • Instructions for groups or sections MUST be visible.
  • Instructions for groups or sections SHOULD be visually adjacent to the grouped elements.
  • Instructions for groups or sections SHOULD be adjacent in the DOM to the grouped elements.
  • If the instructions for groups or sections are not critical, the instructions MAY be hidden until the user requests them.
  • Instructions for groups or sections MUST NOT rely solely on references to sensory characteristics.

Instructions for Inputs

  • Instructions for an element MUST be programmatically-associated with the element.
  • Instructions for an element MUST be available as programmatically-discernible text.
  • Instructions for an element MUST be meaningful.
  • Instructions for an element MUST be visible.
  • Instructions for an element SHOULD be visually adjacent to the element.
  • Instructions for an element SHOULD be adjacent in the DOM to the element.
  • If the instructions for an element are not critical, the instructions MAY be hidden until the user requests them.
  • Instructions for an element MUST NOT rely solely on references to sensory characteristics.

Required Fields

  • Required fields SHOULD be programmatically designated as such.
  • Required fields SHOULD have a visual indicator that the field is required.
  • The form validation process MUST include an error message explaining that a field is required if the field isn't identified as required both visually and programmatically in the form's initial state.

Download Summary & Checklist

Tips & Tricks

  • Ensure Labels and Instructions Are Clear and Informative
  • Ensure Labels, Instructions, and Advisory Information Can Be Seen with Screen Magnification Turned On
  • Make Instructions and Advisory Information Available to Screen Readers
  • Clearly Disclose Constraints for Form Fields
  • Clearly Identify Required Fields

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Dynamic Forms & Custom Widgets

Checklist - Deque

Changes in Context

  • Focusing on an element MUST NOT automatically trigger a change of context, unless the user has been adequately advised ahead of time.
  • Changing an element's value MUST NOT automatically trigger a change of context, unless the user is adequately advised ahead of time.
  • Hovering over an element with the mouse MUST NOT automatically trigger a change of context, unless the user has been adequately advised ahead of time.

Custom Form Inputs

  • Native HTML form elements SHOULD be used whenever possible.
  • Custom form elements SHOULD act like native HTML form elements, to the extent possible.
  • Custom form elements SHOULD have appropriate names, roles, and values.
  • Updates and state changes that cannot be communicated through HTML or ARIA methods SHOULD be communicated via ARIA live messages.

Download Summary & Checklist

Tips & Tricks

  • Avoid Shifting Focus Automatically without User Input
  • Avoid the Automatic Submission of Forms
  • Utilize Standard Controls for Forms, and Use Them in the Standard Way
  • Provide User Enough Time to Complete Tasks or Forms

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Form Validation

Checklist - Deque

Error Identification Considerations

  • Error feedback SHOULD be made available immediately after form submission (or after an equivalent event if there is no form submission event).
  • Error feedback MUST be programmatically-associated with the appropriate element.
  • Error feedback MUST be programmatically-discernible.
  • Error feedback MUST be meaningful.
  • Error feedback MUST be visible.

Success Confirmation Considerations

  • Success confirmation feedback SHOULD be programmatically-discernible.
  • Success confirmation feedback SHOULD be meaningful.
  • Success confirmation feedback MUST be visible.

Download Summary & Checklist

Tips & Tricks

  • Help Prevent User Errors
  • General Approach to Error Handling
  • Provide Clear and Actionable Information Regarding Detected Errors
  • Shift Focus to Error Messages
  • Ensure Errors and Alerts are Indicated the Same Way Site-wide
  • Facilitate Error Repair and Resubmission
  • Provide the Ability to Prevent and Correct Errors on Forms (Legal and Financial Transactions)

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Using Forms with Screen Readers

Checklist - Deque

Introduction category

None documented

Download Summary & Checklist

Tips & Tricks

None documented

Jump to:

Guidelines

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented