Authoring accessible forms

Start of documentation content

Formally gives you the tools to make accessible forms quickly, but there are still many things to learn.

There are numerous subjects not covered in this documentation. We recommend the 'Further reading' section below.

Always use labels

A form field label is the textual description of the kind of information that a user should provide e.g. Name, Email, or DOB.

(Formally allows HTML content for labels so DOB could be better written as <abbr title='Date Of Birth'>DOB</abbr> to clarify the acronym).

Ensure the label text makes sense to all types of users of your form.

Choose hints

A form field hint can give additional context and example answers to a form field. A hint for an email field might be e.g.

Avoid placeholders unless necessary

Placeholders are text that is displayed inside empty text boxes, and these placeholders are hidden when the field has a value (is non-empty).

As such it's possible for users to confuse placeholders for their answers which is more likely than you might first think due to browser's prefilling some fields, and long forms.

Unless you have a specific use-case for placeholders, a limited set of users that prefer them, or testing that indicates otherwise, we discourage placeholders and instead recommend using hints.

The autocomplete

Providing responses in a form can be an accessibility barrier (e.g. some kinds of motor impairment make it difficult to provide any answers), so if a browser can prefill answers it can help include more people.

Browsers can prefill some types of answers using autocomplete (MDN autocomplete) such as:

  • Name
  • Email
  • Address
  • (etc)

WCAG 2.1 requires the correct use of autocomplete so be sure to configure it.

Automated testing

While there are limits to what automated software can detect (ie, it can't check if a form label is described incorrectly) they can catch some mistakes and so they are a useful part of your accessibility toolkit.

Be sure to test forms in,

Manual testing

Test forms with actual users to see if they're able to easily provide answers.


Groups of form fields can be given additional context by grouping them with fieldsets.

The textural description of a 'fieldset' is called a 'legend'.

A popular example is that of delivery and billing addresses. Each of these would have many form fields: street address, suburb, city, state, and country. By grouping them under a fieldset and using a legend of "Delivery address" and "Billing Address" you can give the additional context to help users fill in the form.

Further reading

Further reading for accessibility engineers / developers