Accessible forms

When designing forms on the web, one common pattern is to display each field with the possibility to validates their content and to put the eventual errors next to the fields themselves.

For instance, let’s imagine a login form with an email field, a password field, and a submit button. For each of these elements, there is a set of rules to apply:

• the email should have a valid format
• the password should be at least 12 characters long
• the submit button is disabled until the email and password fields are valid

The following Codesandbox is an example of such a login form you can play with. It’s built using Formik.

While this seems to follow the rules set before and that the UI seems to fill the designers’ expectations, there is an issue. Let’s check what happens when using this form with a screen reader in this video.

In this video, I’m using VoiceOver (the official OSX screen reader). While being able to navigate using it, I don’t have direct feedback about the invalid fields. In order to get informed, I need to scan the whole form again and check every text content in it.

With the intent to provide a better experience to screen reader users, we can:

• put an aria-invalid attribute on fields that are in an invalid state so that screen readers can provide that information
• put an aria-describedby attribute on the error element (in the example, the one showing “Invalid email address”) so that when focusing the input, screen readers also announce the error content
• remove the disabled attribute on the submit button so that the user can click on it. When pressing it, the browser will focus on the first field that is in an invalid state or submit the data if every field is valid.

The following video shows how making these modifications help to provide feedback to screen reader users.

In addition to this video, the following is a Codesandbox providing an example of the login form built in a more accessible way, also using Formik.