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:
- Every form control has a label
- Explicit required form fields
- Explicit formatting requirements
- They are keyboard accessible
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. --> <label> <span>Name</span> <input type="text" /> </label>
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
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:
- When we press the password's visibility button (by mouse or keyboard) the form is also submitted (you'll see the same log).
- When we press "Enter" in any input, the password is algo toggled.
Why does that happen? The default type of a
"submit". When a button inside
<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="submit") when used inside forms to avoid unwanted form submissions.