A practical guide to accessibility for forms

Written by Adewale Abati✏️

Introduction

From the moment we start learning to code, one thing that is difficult to do without is collecting data for interactions from users. And to collect data from users, we need some type of form.

From collecting reviews to registering, logging in, making purchases, or providing feedback in our applications, we use forms. Forms are a critical part of the web, hence, we must ensure that everyone is able to interact with them regardless of disabilities.

Why it’s important

Accessibility is often perceived only as a way to accommodate blind users, but it goes far beyond just that. There are varying forms of disabilities, which include temporary disabilities like hand or arm injuries, situational disabilities like slow internet, and permanent ones like blindness and others.

We want to make sure all of our users are able to use forms without having a poor experience at any point in time, and the goal is to make these key user interactions as frictionless as possible. When forms are made accessible, they are easier to use for not just people with disabilities, but for everyone.

It is also important to note that it’s increasingly important — and gradually becoming a legal requirement — for businesses to comply with web accessibility standards across many countries, including the United States, United Kingdom, and Canada.

In 2016, Target paid millions to the National Federation of the Blind because there was no alt text on their product images, among other accessibility issues. Just recently, the U.S. Supreme Court rejected a petition from Domino’s after losing in a lower court to a blind man who had sued the company after being unable to make an order on its website despite using a screen reader.

It’s only a matter of time before more countries adopt similar laws and create even more standards, giving websites clear steps to follow to achieve accessibility.

Things to consider

As we try to improve existing forms or create new ones, here are a couple things to figure out to identify the steps we need to take:

• Is it easy for the user to determine what information they need to provide and in what formats?
• What difficulties might someone with visual impairments have when using the form?
• Is the form well processed by screen readers?
• Is the form logical and easy to understand?
• Can users fill out the form using only their keyboards?

How to make accessible forms

There are a number of ways to help improve forms and make them closer to being completely accessible to everyone. Here are a couple recommendations:

Write semantic HTML

This is number one because a lot of accessibility issues can already be taken care of if the right HTML element is used. There are over 100 HTML elements, each with a unique purpose to carry out a task.

Thanks to the constant improvements in HTML, it is usually unnecessary to use another element laced with custom JavaScript code to make it function like another element because of customizations. Use a button element in the right place instead of customizing a div to look and function like a button. This makes it easier for screen readers to provide more information about the element to the user.

Use appropriate HTML input types

There are numerous HTML input types, each one created to make it easier to retrieve a specific type of data from the user. By specifying the right type and name attributes — e.g., type="password" to help hide the text shown, type="email" to collect emails — the browser becomes optimized to receive the data and also provide autofill suggestions to the user.

On mobile, using the correct input types shows the appropriate keyboard. For example, when using type="tel", the keyboard displays a keyboard to input phone numbers, while type="email" shows a keyboard with the @ button prioritized.

Also, please use <input type="submit"> to create the submit button for your form. This will enable users to submit by simply pressing the enter button on their keyboards.

Connect HTML input types to their labels

I think labels are one of the most underrated elements in HTML. They are quite powerful and make a lot of things work better. Aside from the presentational purpose of knowing what data the input is requesting, it can be taken a step further.

By connecting labels directly to the input using the for attribute, we can have increased usability.

<label for="hungry">Are you hungry?:</label>
<input type="checkbox" name="hungry" id="hungry">

With this, we get a larger target size for each input element because clicking on the label puts the input in focus. This is useful for people with motor disabilities, especially when they have to select smaller elements like a radio or checkbox. Screen readers also read out the connected label for an input instead of simply calling out what input type it is when in focus.

The for attribute of the <label> tag should be equal to the id attribute of the related element to bind them together, as shown in the example above. For users without visual disabilities, it should also be easy to visually associate a label with its connecting form field.

Only use placeholders to describe the value intended

On some occasions, users are left with just the placeholder in place of labels telling them what should go in each input. The problem with this approach is that once the user starts typing, the placeholder disappears.

People with cognitive disabilities also tend to have issues with placeholders because it can be assumed to be prepopulated text. Please avoid providing instructions via placeholders; they’re not a replacement for labels.

Provide additional help text

Depending on the type of data required from a form, it’s good practice to include instructions when needed at the top of the form. Since only one <label> element is allowed per field, in situations where you need to provide descriptive text for the input, it can be linked with the form field using the aria-describedby attribute. Screen readers will announce both the label and this help text when the form field has focus.

<label for="employment_date">Employment date:</label>
<input type="date" name="employment_date" id="employment_date" aria-describedby="employment_date_help">
<span id="employment_date_help">MM/DD/YYYY</span>

It’s also recommended to include examples of input data instead of long descriptive messages, as it’ll be easier to understand for users.

Group related form controls

In situations where you have to provide multiple controls for a purpose — usually when using radio buttons or checkboxes — it’s highly recommended to use the <fieldset></fieldset> element to group them, and then use <legend></legend> to provide their descriptive text.

Using <fieldset></fieldset> and <legend></legend> ensures that the text description is read to screen reader users once the grouped controls are in focus.

Accessible validation

Validations on forms are done either server side or client side using JavaScript. HTML5 provides a range of in-built functionalities to help validate inputs like email addresses. When errors occur, it’s important to show them to the user in an accessible manner — which includes making it easier for users with screen readers.

To do this, error messages should be displayed with the attribute role="alert" on them since screen readers support this and would notify users immediately of the error. Error messages can also include suggestions or examples to make it easier for the user to correct the error.

A common practice is to sum up all errors and add them to the top of the form, but it’s better to associate errors directly with the input. Add the error messages below, connect them with aria-, and visually indicate which input fields have errors.

For required input fields, they should be identifiable using labels. HTML5 also provides the required attribute that can be added to form controls to indicate they are required. This attribute is supported by modern web browsers and communicates required inputs that are missing to users.

Conclusion

Forms are critical to the general usability of a web application because they are used for varying types of interactions on the internet. Using the right HTML elements takes us a step closer, but making the conscious decisions to put additional things in place ensures that every user, regardless of their disabilities or lack thereof, will be able to use our forms.

To find out even more ways to make the entire web experience accessible for users, Web Content Accessibility Guidelines (WCAG) 2.0 provides instructions that will make content accessible to a wide range of people with and without disabilities.

As we improve accessibility and usability for our forms, everyone benefits.

Editor's note: Seeing something wrong with this post? You can find the correct version here.

Plug: LogRocket, a DVR for web apps

 

 
LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.
 
In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.
 
Try it for free.

The post A practical guide to accessibility for forms appeared first on LogRocket Blog.