Go Back

3.3. Accessible forms


Forms are used for many types of interactions on the web. When we talk about the accessibility of forms we are usually referring to their accessibility regarding people who use screen readers or keyboards. However everyone benefits from a well-organized, highly usable form, especially those with cognitive disabilities. Forms should be clear and intuitive.

When building forms we should make sure that:

The most basic rule is to make sure every form control has a respective label.

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

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

If we do that with every form element, it's already a step forward! There's a lot more about creating accessible forms that we'll learn step by step.


In the exercise page, there are 5 form controls. However, each one has a particular accessibility issue.

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

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

Hint 2: You can also use the Accessibility tab on DevTools to know how a form control is pronounced by a screen reader.


#1 ARIA Live regions

When submitting the form, a message is shown dynamically based on the submission result (success or invalid).

While these changes are visually apparent to users who can see the page, they may not be obvious to AT users, such as screen reader users.

ARIA live regions fill this gap helping to expose this dynamic content.

<!-- The content is announce immediately when added to the DOM.
Use it when it's critical information.  -->
<div aria-live="assertive">The form you tried to submit is invalid.</div>

<!-- The content is announced when there's a change (idle).
Use it when this do not influence the user main task.  -->
<div aria-live="polite">Now playing "Pink Floyd - Time"</div>

🎯 Goal: Explicit mark the form feedback messages as dynamic content.

Here's a codepen example exploring multiple ways of using aria-live. In this exercise the code is ready to follow the approach #3.

#2 Using buttons inside forms

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

You may have noticed that each button in the form has its type explicit. Usually this isn't done because we think it's not needed. Let's remove the 2 types (button and submit) and see what happens.

When the form is submitted, you'll see a log Form submitted! on the DevTools console. Give it a try now: Click "Submit" to see it by yourself.

There are now 2 bugs happening:

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 toggle password. That's why when we click it, the form is also submitted.

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