3.3. Accessible forms

Introduction

When talking about the accessibility of a form, usually we are talking about their accessibility regarding people who use screen readers or keyboards. However everyone benefits from a well-organized and usable form, especially those with cognitive disabilities. Forms should be clear and intuitive.

When building forms, we need to ensure that:

First things first, a form control must always have a respective label.

<!-- Option A: Use for and id to connect both elements -->
<label for="uName">Name</label>
<input type="text" id="uName" />

<!-- Option B: Wrap the text and the input in a <label>.
  The browser will connect both. -->
<label>
  <span>Name</span>
  <input type="text" />
</label>

If we ensure these labels in every form element, it's already a half way done!

Exercise

In the exercise page, there are a few form controls. Each one has a particular accessibility issue.

🎯 Goal: Make the form accessible for keyboard and screen readers.

Hint 1: SR users usually prefer to fill forms using Tab key. Do the same to detect A11Y issues.

Hint 2: Use the Accessibility Tree tab on DevTools to know how a form control is announced.

Bonus

#1 Better input numbers

In one of the fields, we used type="number" to benefit from the virtual keyboard. However, that approach still has some A11Y issues that can be overcomed with another strategy:

<input type="text" inputmode="numeric" pattern="^[0-9.]*$" />

That pattern accepts numbers and dots (eg 10, 15.50).

References:

#2 Using buttons inside forms

This is already done, but let me explain this common form mistake:

  1. In the exercise page, please remove type attribute from both <button> (password toggle and submit).

This creates 2 bugs:

Why does that happen?

The default type of a <button> is "submit". When a button inside a <form> is clicked, the form will look for the first "submit" button and trigger it. In this form, the first button is the password toggle. That's why when we click it, it submits the form too.

Takeaway: Always explicit the button type (type="button" or type="submit") when used inside forms to avoid unwanted form submissions.

#3 Form feedback

Already here? You were fast!

When submitting the form, a feedback message is displayed, based on the form result. Although these changes are perceivable to those who can see the page, that's not the case for those who use a screen reader. How would we solve this?

To solve this, we first need to learn about Live Regions. That's what will explore in the next exercise. You can take a pick there and use it to solve this exercise.


Further reading

WCAG Success Criterion

Exercise takeaways

(After the exercise) Reveal takeaways