The Anatomy of Accessible Forms: The Problem with Placeholders
The other day, I was filling out an online exam registration form. They asked me to write my office address, home address, work phone, and home phone. I filled all the details without any issues. However, when I wanted to verify whether I filled in all the details in the right fields, the text “Office address” or the texts for any other fields disappeared. What do I do now? Do I re-enter the data into the field to make sure I am correct? Unfortunately, that is the only way, which is time-consuming and frustrating.
The placeholder attribute specifies a short hint that describes the expected value of an input field (e.g. a sample value or a short description of the expected format).
The short hint is displayed in the input field before the user enters a value.
The placeholder attribute works with the following input types:
- Text
- Search
- URL
- telephone
- password
Placeholder is introduced in HTML5, and since then it has become a rather important attribute that is widely used. Developers, and designers many times want to use a placeholder in lengthy forms as they believe it is more appealing than a visible label. This is because it occupies less space on the screen and renders the design for smaller screens better than short hints.
In part one of the series on accessible forms, we will see why using a placeholder is not great from the accessibility standpoint and how to use a placeholder attribute successfully.
Avoid the Placeholder Attribute
According to the research conducted by Nielsen, it is not best practice to have a placeholder in the form field from a user experience perspective. This is because many users are confused by placeholders. In particular, people with cognitive disabilities tend to have issues understanding placeholder text because they think it is pre-populated text and will try to submit the form without entering their specific information.
Placeholders Fail Color Contrast
The default color of a placeholder in a form field is light grey, which often doesn’t pass the Web Content Accessibility Guidelines (WCAG) Success Criteria 1.4.3 guideline. According to the WCAG SC 1.4.3, the visual presentation of text and images of text must have a color contrast ratio of at least 4.5:1, and different browsers render placeholder differently. For the placeholder to pass successful color contrast requirements, proper CSS must be used:
Sample CSS Code for Placeholder
0 1 2 3 4 5 6 7 8 9 |
::-moz-placeholder { color: #333; opacity: 1; } ::-webkit-input-placeholder { color: #333; } |
A Placeholder Is Not a Replacement for Visible Labels
In recent years, placeholders are being used to provide visible labels for the form fields, which is a bad user experience and accessibility practice. This is because placeholders disappear once the user inputs the data into the form controls, the user does not have any idea of what the form field is referring to. This also holds true for people with short term memory, people with traumatic brain injuries, people with Autism, people with ADHD, and people with low vision.
Avoid Providing Instructions Using a Placeholder Attribute
Instructions help users to submit the form successfully. However, if the instructions are provided with a placeholder attribute, then the user might not be able to use that instruction effectively. As placeholders disappear when the user starts filling in the form, users might miss critical information. For example, password instructions should not be provided using a placeholder attribute.
Example Syntax for Password Placeholder
0 1 2 3 |
<label for=”password1”>Password</label> <input type=”text” id=”password1” placeholder=”Password should be 8 characters with one number, one special character”> |
Preview
In the example above, the password needs a special character, a number, and the password must be 8 characters long. This can become more complicated if more variations are added to the instruction.
In order to reduce confusion or user error, always provide instructions in the form of text that is visible to the user and associate the instructions to the form controls using the aria-describedby method for screen reader users.
Example Syntax for Static Hint
0 1 2 3 4 |
<label for=”password”>Password</label> <input type=”text” id=”password” placeholder="enter password" aria-describedby=”password-hint”> <span id=”password-hint”>Password should be 8characters long with a number & a special character</span> |
Preview
Password should be 8 characters long with a number & a special character
In the example above, we can see that password hint is constant while the data is being inputted into the form control.
It is important to note that not all screen readers and browsers support the placeholder attribute. If it is not read by a screen reader, the information may be missed by a screen reader user.
Furthermore, users will not be able to verify if they entered the right data into the form controls if the placeholder is used as a visible label. The required validation is a huge cognitive burden on all users, including people with disabilities.
There is a growing trend where the placeholder is being used as visible labels, but instead of the placeholders disappearing when data is entered, they float above, below, or to the side of the form control. These are called floating labels. While there are mixed opinions from various design and accessibility practitioners on floating labels, we advise to test them with users. For more information on the floating label subject, you may refer to the following articles:
- Floating labels are problematic
- Are Float Labels Really That Problematic After All?
- Floated Labels Still Suck
In my opinion, it is the best user experience for everyone if the placeholder is used as it is intended in the HTML specification. If you choose to use a placeholder, it should be used for short hints only.
Points to Remember
- Avoid Placeholders if possible
- Make sure that placeholder color contrast meets WCAG requirement of 4.5:1
- Don’t provide critical instructions with a placeholder attribute.
- Provide instructions below the form control and; associate them using aria-describedby to the form control.
- If there is no other option than to use a placeholder as a replacement for a visible label, use one of the floating label methods.
Well explained!!!
I have a question here, now a days I have noticed that, many websites/Web pages having float label pattern for form fields. When we use float label pattern we can’t use placeholders. As you said instructions/hint cant be given in the form field when float label pattern is used. In this case how to fix hints related issues for float label pattern.
Thanks in advance.
Currently, the live examples show incorrect placeholder texts. Probably, because they use incorrect quotation marks. E.g., instead of showing “enter password”, it shows “”enter”.
Thanks for the catch Gerrit!
Hi, I like this article a lot. I even used it as a reference in my suggestion to prevent axe-core change: https://github.com/dequelabs/axe-core/issues/2413
I hope they will consider the points you made in the article as change in axe-core could have great implications.
I was wondering what you thought about bolding the labels? That appears to be something I cannot find much research on. I see it a lot, but I also see designs where the labels are smaller in size and capitalized, for example. They are still 508 compliant, but they have a different style.
Thoughts?
Hi, great points about the placeholder, thanks!
About the placement of the hint text (instructions), 4 possible advantages for placing it between the label and input field rather than below the input field:
– It is more logical – users are expected to read it before they entered data
– It is not hidden – in case the form is in scrollable area and the hint text is out of view
– It is not hidden 2 – in case browser’s autocomplete covers it
– It can make the field target area larger – for accessibility reasons. This requires placing the hint text within the element contained within
This approach is recommended for instance by GOV.UK (https://design-system.service.gov.uk/components/text-input/) and by Adam Silver in his Form Design Patterns book (https://www.smashingmagazine.com/printed-books/form-design-patterns/)