Accessible Forms 101

Accessible forms don’t need to be difficult

Form accessibility can sometimes seem like a daunting task, especially when faced with a complicated design, or fields that require complex validations. This topic covers the core basics, and by following these four steps you can create accessible forms for a wide range of standard use cases. Once you’ve mastered the basics, hop on over to Handling Validation Errors in Forms for some more tips, and keep an eye out on Up Your A11y for some future topics that deal with more complex form UIs.

Step 1: Make sure your inputs are labelled

Getting back to basics, the most fundamental building block of an accessible form is clearly labelled form inputs. Every input in your form should have a unique ID and corresponding label. Even though you may have placed descriptive text directly above or next to the input, there is no guarantee a screen reader user will read the content, as they will usually tab directly to the form input itself (See: Getting Started with Keyboard Navigation and Screen Readers). Turn on your screen reader and consider the following example:

You will notice that although this looks OK on the page, when you tab to the input there is very little information provided; on VoiceOver it announces “edit text, blank”. This can be remedied by using the appropriate label element, and ‘for’ tag, as in the code example below. By adding this label, VoiceOver will now announce “First name, edit text”. The form input rendered by this example is also included below so you can turn on your screen reader and hear the difference:

Designs without labels

It is often the case that you may want to use the placeholder attribute to communicate the purpose of the input, for example:

If you switch on your screen reader and tab to the above input, you’ll notice that the placeholder text is read aloud, so it may seem like this is enough for screen reader users. However as soon as you have entered text into the field, the placeholder disappears and there is no longer any label or information about what the text field is for (go ahead - try using the screen reader to focus on the above input after you’ve entered text in it).

The above effect can be achieved accessibly, by either positioning a label hidden off-screen using CSS, or by using the aria-label attribute:

Turning on your screen reader and tabbing to the input below will show that the aria-label is read out to the screen reader user, regardless of whether text has already been entered in the field or not; keeping both the design and the user experience intact.

Step 2: Take the guess-work out wherever possible

Labels communicate to the user what kind of information is expected in a given input, but often we have other requirements that might not be immediately obvious, for example:

• A field that is required
• A maximum or minimum length on a text input
• A password creation input that requires special characters
• A phone number input that shouldn’t include any spaces

While it can be easier for sighted users to quickly consume validation error messages and correct mistakes, it is better user experience for everyone to have the information upfront to avoid errors in the first place.

For required fields, you can add the “required” attribute to your input which lets screen readers know to inform the user this field must be completed:

Consider also adding descriptive text alongside your label/input communicating any special requirements for the user input. For example:

Notice in the example above, the “aria-describedby” attribute has been used. This ensures that the descriptive text is read out to screen reader users along with the input’s label. You can switch on your screen reader and test drive the example below:

Step 3: Get organised

Large forms can be difficult to consume for all types of users, especially those using assistive technology. You can ease the burden by splitting your form into groups of related details using the ‘fieldset’ and ‘legend’ elements, helping the user to understand when they have reached a new section of the form.

These groupings become even more essential when input types such as radio are considered. For example, a basic form might have a set of radio options, e.g.

While each input has its own label describing the value of the radio button, all of the inputs relate to each other and need to be understood as options under a particular question - “Your marketing preferences”. Using fieldset and legend allows us to label the group, as well as the individual inputs:

Step 4: Keep it minimal

A minimal form is always going to be easier for users to complete with minimal effort, and it’s therefore worth considering carefully before adding any extra bells and whistles. For example, many form designs include the use of tooltips instead of placing descriptive text clearly on the page (as in Step 2 above).

Tooltips might be visually appealing (although the question is open as to whether your sighted users would actually prefer not to have to hover over an element for details), but if you add them to your form you will need to ensure:

• The tooltip is keyboard accessible - i.e. a user can trigger the appearance of the tooltip text by focusing the item with the keyboard instead of hovering with the mouse
• Your screen reader users can readily access the same information, e.g. you could position some text off-screen using CSS and set the aria-describedby attribute as per Step 2 above.

Next steps

Now you have the basics in place, check out Handling Validation Errors in Forms, which will give you some tips on how to handle invalid inputs and errors. Keep an eye out for more advanced Form topics on Up Your A11y coming soon, and in the meantime, check out the further reading suggestions below.