Forms

Form Instructions

Once a screen reader encounters a form, it may ignore everything except for form labels, controls, and legends. Therefore, developers must be careful to provide instructions in such a way that will be perceived by screen reader users.

Instructions that apply to the whole form should be included before the <form> element. 

Inline instructions should be visually placed close to the control they describe. Inline instructions must be associated with the form describe using aria-describedby. If input must be in a specific format, provide that format in the inline instructions.

Yale recommends that placeholder text never be used to provide labels or instructions for form fields.

See the WAI tutorial on form instructions for more.

Form Controls and Labels

Yale recommends that developers always use native form controls and labels where possible. Using JavaScript to create custom widgets such as checkboxes, radio buttons, and selects presents substantial accessibility challenges, as developers must remember to manually add functionality for keyboard-only and non-sighted users. (Such functionality is available by default in native form controls like <input> and <button>.

Form controls must be given an accessible name. Use label elements to provide accessible names to native form controls where possible. If a label element cannot be used, an accessible name can be provided using ARIA:

• Using aria-label to provide an invisible label where a visible label cannot be used
• Using aria-labelledby to provide a name for user interface controls

Developers must ensure that the visual label for a form control matches that control’s accessible name. Speech input users can have difficulty using controls where the accessible name does not match the visual text describing the form. Sighted screen reader users also have a better experience when a control’s visual label matches its accessible name.

Groups of radio buttons must be wrapped in a <fieldset> with a <legend> that describes the purpose of the radio buttons. Groups of checkboxes must also be wrapped in a <fieldset> with a legend unless the label for each checkbox is sufficient to describe the checkbox’s purpose completely.

Groups of associated form controls (e.g. a group of text boxes for first, middle, and last name) may also be wrapped in a <fieldset> with a <legend> describing their purpose.

Be sure to provide highly visible focus states for form controls. Browser default focus states may not be salient enough for keyboard-only users.

Form Layout and Linearization

Screen reader users and keyboard-only users encounter form controls according to their source order. Therefore, it is important that the source order for form controls be sensible. When form controls are presented in a single column, that is easy enough. But when form controls are presented in multiple columns or other complex layouts, developers should take care that the source and tab order makes logical sense.

Marking Fields Required

Developers may use color to indicate which fields are required, but they must not use color alone.

If using HTML5, required form controls should have the required attribute. For older versions of HTML, required form controls should have the aria-required=”true” attribute. Additionally, developers may want to include the word “required” or include an asterisk as part of the label itself (rather than using the CSS ::after selector).

A simple asterisk alone for indicating a form field is required is likely not sufficient to ensure an accessible experience. If an asterisk is added through CSS (for example, using the ::after selector), screen readers or users who have disabled styles or use alternative stylesheets may not be aware that the field is required. Therefore, combine asterisks or other symbols with the techniques discussed above.

When styling required fields to make them more noticeable, be sure to provide high color contrast (at least 4.5:1, including asterisks or other icons).

Validating Form Input

Form fields with invalid input should be given the aria-invalid="true" attribute. This allows screen reader users to be alerted which form fields need addressing. Additional styling, such as a colored background, for invalid input may be helpful. When providing such styling, provide high color contrast.

In general, forms should be as tolerant of various input formats as possible, in order to reduce the cognitive demands of a form. Error messages should likewise be as helpful as possible in prompting users how to resolve an invalid form submission.

Users should always receive feedback when a form is submitted, regardless of whether a submission is successful. A proper feedback approach should encompass both overall feedback and feedback specific to particular form controls.

Overall feedback can be provided through messages in the page <h1>, the page <title>, JavaScript alerts, or modal dialogs. Additionally, listing errors at the top of the page in a region marked role="alert" may be helpful.

Inline feedback should be provided immediately after a field and be associated with the field using aria-describedby.

When providing feedback after submitting a form, focus should be set in such a way that helps users find which form fields should be corrected. If providing an error message at the top of the form, set focus to that message. Otherwise, set focus to the first invalid form control.

WebAIM’s page on Form Validation and the WAI’s page on User Notifications provide further discussion for error validation.

Giving Users Enough Time

Users with impairments may need more time to complete a process. The accessibility guidelines Yale has adopted require that the needs of users with disabilities be taken into account whenever a time limit is imposed on a website. Where possible, do not require a time limit to complete a form. Only require a time limit if there is a strong business, privacy, or security reason to do so.

If timing is required, users should be given at least one of the following options:

• turn off the time limit
• adjust the time limit to extend up to 10 times the default time limit
• be given 20 seconds to extend the time limit before timing out, and be given the option to extend the time limit up to 10 times

Exceptions are only allowed if the time limit extends at least 20 hours or if the time limit is essential to the activity, such as in a timed auction.

For more information, see WCAG 2.2.1: Timing Adjustable.

Allow Users to Review Data before Submitting

In general, users should be given every opportunity to avoid or correct errors on their form submissions. In cases where users are submitting data that creates a legal commitment, executes a transaction, or otherwise carries substantial consequences for inadvertent or incorrect submission, special care must be taken.

In such a case, at least one of the following must be true:

• the submission must be reversible 
• the submission must be checked for errors and the user must be given an opportunity to resolve the errors
• the user must be provided a process for reviewing, confirming, and correcting the information prior to submission. 

For more information, see WCAG 3.3.4: Error Prevention.