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:
- Every form control has a label
- Required fields are explicit
- Requirements / errors are understandable
- Forms are navigatable by keyboard
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:
- In the exercise page, please remove
type
attribute from both<button>
(password toggle and submit).
This creates 2 bugs:
- Press the password's visibility button (by mouse or keyboard). The form is also submitted (check the logs in the console).
- Press "Enter" in any input, the password is also toggled.
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
- Creating Accessible Forms
- Codepen: 1 label can only have 1 input
- Short note on aria
aria-label
,aria-labelledby
andaria-describedby
. - Using
aria-live
- Accessibility Inspector (Chrome)
- Accessibility Inspector (Firefox)
WCAG Success Criterion
- WCAG 1.3.5 Identify input purpose - Level AA
- WCAG 3.3.1 Error identification - Level A
- WCAG 3.3.2 Labels or instructions - Level A
- WCAG 3.3.3 Error suggestion - Level AA
- WCAG 4.1.3 Status messages - Level AA
Exercise takeaways
(After the exercise) Reveal takeaways
- Every input must have a name, always. It can be through
<label>
,aria-label
oraria-labelledby
. - Do not use
placeholder
as labels because it disappears after the input is filled and can confuse the user. - Inputs are more than labels. Remember the other 3 states: required, error and descriptions.
- Use
<fieldset>
and<legend>
to group similar inputs. - Use the attribute
inputmode
to better customize the keyboard layout in touch devices.