Design a form

On this page:

Overview
Use the <form> element
Choose your form field type
Include a submit button

Overview

A well-designed form should be easy for everyone to complete. There are many form elements you can use to get input. Choosing the best form element for each question makes the form easier to complete by matching how people expect particular form fields to work. This is especially important for making your form accessible.

Before choosing which form fields to use in your form, see Plan a form to learn about crafting clear questions.

Use the <form> element

To make a form accessible, place groups of data-gathering elements in a <form> element. This lets certain screen readers work correctly by triggering the "forms" mode. A <form> element may be optional for one or two buttons but is otherwise needed. Note that a form cannot be nested inside another form.

Understanding screen reader interaction modes: Léonie Watson explains the different modes (virtual/browse, forms, and applications) that Windows screen readers use to interact with content.
The form element: Mozilla Developers Network (MDN) documentation on the <form> element.

Choose your form field type

The type of form field can affect how easily someone can complete your form. See Mozilla's guide to native form fields for help matching the type of data to the most suitable form field.

Use semantic HTML form elements whenever possible. Semantic elements have meanings that indicate the purpose or role of the element, and those meanings can be shared through assistive technology. They provide expected functionality and behaviors that improve accessibility and help everyone complete the form. For more on semantic HTML, see Semantics in HTML from Mozilla.

Note:

Avoid using non-form elements in a form. Some assistive technologies will ignore any content not programmatically associated with a form element.

Choose form fields that are appropriate for the type of information you are collecting, and always consider usability and accessibility.

When choosing what types of form fields to use, ask yourself:

Does the question require typing a response?
Does the text require a specific format, such as for an email address, telephone number, or date?
Does the question require selecting from a limited number of options?
Can only one option be selected or can multiple?
Are the options on a range or are they discrete values?

See the BBC guidelines on inputs for more recommendations for specific form fields.

Common form fields for text responses

Text

Use <input type="text"> for a response that requires a single line of text.

Textarea

Use <textarea> for a response that requires multiple lines of text.

Specific formats

Some input types display a customized keyboard layout for people using mobile devices, making it easier for them to enter the required data. If you are collecting a specific type of data, such as a phone number or a password, consider one of the following.

Telephone numbers: <input type="tel">
URLs: <input type="url">
Email addresses: <input type="email">
Passwords: <input type="password">
Dates: <input type="date"> (should specify format)
Numbers: <input type="number"> (not for numeric data such as credit card numbers and postal codes)

Note:

<input type="date"> is not supported in all browsers and is not accessible to all assistive technology.

For details about the 21 possible input element types, see States of the type attribute, a section of the HTML 5.2 specification.

Common form fields for selecting from a set of options

Radio

Radio buttons imply that you can only select one option. To be accessible, radio buttons must be grouped. Radio buttons (<input type="radio">) are best for a few options.

Checkbox

Checkboxes imply that you can select zero to all options. To be accessible, checkboxes should be grouped. An exception to this is a single checkbox, clearly labeled. Checkboxes (<input type="checkbox">) are best for a few options.

Select

Use selects for few or many options. Selects (<select>) with one or more <option> elements nested can be used to select a single option, which is the default behavior, or modified with the "multiple" attribute to let people select multiple options.

Simple selects should be accessible. If your select is complicated, there are some accessibility considerations:

The "optgroup" element is not fully supported by all assistive technologies. If the grouping labels are needed for understanding, consider redesigning the select, perhaps by using a series of two or more selects.
Keyboard interaction with the "multiple" attribute is not intuitive in all browsers. If multiple items may be selected, consider using checkboxes instead.

Slider

Use sliders for values in a range. Sliders (<input type="range">) are best when exact values are not important.

Complex form fields

Listbox

Use the native <select> whenever possible. If you are unable to use the native HTML <select>, use the Accessible Rich Internet Applications (ARIA) "listbox" role.

ARIA: Listbox role: This Mozilla Developers Network (MDN) article has hints for creating an accessible listbox, including expected keyboard interactions and examples.
Listbox: The ARIA Authoring Practices documentation explains how to create accessible listboxes, describes expected keyboard interactions, and offers links to examples.

Combobox

Use caution when creating a combobox. While the combobox is listed in the ARIA 1.1 Authoring Practices, currently it is not fully supported by browsers or assistive technology.

Differences Between ARIA 1.0 And 1.1: Changes To role="combobox": This article from Level Access describes the differences between ARIA 1.1 and 1.0 when using "role=combobox", the intended use of the ARIA 1.1 combobox, and the state of support for ARIA 1.1. Recommends combobox best practices and includes links to live examples of the ARIA 1.0 combobox.
Combo Box: The ARIA1 Authoring Practices provide information on creating combo boxes, including the expected keyboard interactions. Some issues still exist with the examples, so use these patterns with caution.

Datepicker calendar

Making a datepicker that people can navigate with a keyboard or screen reader is difficult. Because of this, there should always be a way to manually enter a date.

For reasonably accessible datepicker design patterns, see:

Deque University Datepicker Demo: An accessible datepicker demo and design pattern from Deque University.
ARIA Datepicker Demo: An Accelerated Dynamic Content (AccDC) accessible datepicker demo and design pattern from WhatSock.

Include a submit button

To be accessible, a form must have a submit button. Even if the form can be submitted using the Enter key, not everyone can press the Enter key, including people who use voice control.

Use a native HTML <button>, <input type="button">, or <input type="submit"> for built-in accessibility, including expected keyboard functionality. To learn more about the accessibility of native HTML buttons, watch Just use a button [video], a seven-minute Google Chrome Developers A11ycasts episode.

Form buttons need a text label that can be announced by screen readers and activated by someone using voice control. For voice control activation to work, the text label should match or start with any visible button text.

Don't use image buttons. Image buttons present several accessibility challenges, including labeling, image failure, and scaling. The image alt text and any other text labeling for the button must be carefully considered. If images fail, there must be a visible label, and that label needs to fit on the button. Images, particularly images of text, may not increase in size well or at all, making them difficult for some people to read.

Once you have selected your form fields, see Label a form for information on correctly providing labels. You may also want to change the default style of the form fields. To learn more about styling form fields without losing accessibility, see Style a form.