Anyone in the industry long enough has probably read that placeholders are not suitable labels and shouldn’t be used as purpose descriptions on fields. Yet I see this all the time and on some platforms where forms can be generated in a WYSIWYG style editor, it’s the default use for placeholder text either to repeat the label or simply not provide a proper label.
As part of my series on creating better forms by removing bad habits, it’s certainly something I want to revisit because when you use the placeholder attribute as the label – you exclude users.
tl;dr – Short version
The placeholder attribute is for providing a brief hint about the expected input. It isn’t very accessible and it should not be used to display a label or critical information. Better options exist for labels and hints – so not using the placeholder attribute is fine too.
What is the placeholder attribute for?
MDN describes the placeholder attribute as:
The placeholder attribute is a string that provides a brief hint to the user as to what kind of information is expected in the field
And visually, as you’ve probably seen, that placeholder text appears within the field, typically where the value would appear but with small stylistic differences.
To some designers and developers, the placeholder attribute is a really simple solution to a common problem because using a placeholder as the label means you don’t need to mess around with those pesky label tags.
What’s the problem with using placeholder attributes as labels?
Some of you may ask yourself “Well if the placeholder is visible what’s the problem with it being used as a label?”. There are a few answers to why this is a bad approach and I’ll cover them in this post but the stand out problem for me is that you exclude users who have accessibility needs.
Let’s dig a little deeper into how the placeholder attribute works from an interaction point of view. I would characterise the placeholder text like the following:
- Placeholder text will appear in the field where the value would
- Placeholder text that spans beyond the width of the field is not visible
- When clicking into the field and begging to type the placeholder will disappear to make room for the value.
- The placeholder will only return when you delete everything from the field.
So if you interact with forms using a web browser with no assistive tools you’ll recognise the characteristics of a placeholder attribute. For those who require additional help through assistive tools there are a couple more:
- Some assistive technologies don’t understand the placeholder attribute or just ignore it
- By default placeholder text fails accessibility contrast guidelines in some browsers
Placeholder text can easily be confused and hard to read
Looking at the first point, “Placeholder text will appear in the field, where the value would”, it’s easy to see how this may cause a problem for users. When viewing a field with placeholder text a user can easily confuse that placeholder text for the value of the field.
The second point, “Placeholder text that spans beyond the width of the field is not visible”, is another easy one to see a problem with. If you insert too much text into the placeholder attribute your user could have a hard time reading it all.
Remember some users may increase their font size by default, so this could increase the space text takes up in the field and with today’s responsive designs it’s likely that field is going to be visible at different sizes. You cannot scroll placeholder text so anything cut off can’t be read.
For users with accessibility needs, it is very possible that their assistive tech doesn’t even tell them about the placeholder text. So imagine trying to interact with a form that has no associated labels. For users who don’t use specific assistive tools but who may have visual impairments, it could be difficult to even read the text due to the contrast of the text against the field background colour.
Placeholder text is only around some of the time
My third and fourth points highlight an issue with how users interact with placeholder text. The placeholder text is only visible when the field is blank, so if you have inserted text or if your browser has automatically, then you would need to delete the value to see the label – bonkers!
Imagine filling in a long-form with half the fields pre-filled with auto-fill values only to be told of a validation issue and having to manually delete each value and re-add just to make sure the values match what is expected.
So clearly there are usability issues with the placeholder attribute if you use it for labels, but there are issues with it even if you use it for the intended purpose. So let’s try and improve our use of the placeholder attribute.
Making better use of the placeholder attribute
Let’s look at an example. We need to ask the user for their full name with a text field on a web form.
We know the label of the field needs to be “Full Name” or some other descriptive explainer of the field. Since the
<label> tag exists it’s a good idea to use that to describe the field, we associate this label with the field using the “for” attribute.
On the field’s placeholder attribute, I set the value as “Example: John Smith”.
This is a good field because:
- We use the proper tag to label the field
- The label tag is directly associated with the field through the for attribute
- The placeholder text is clearly marked as an example, by prefixing with “Example:”
- The field without the placeholder text would make just as much sense to the user, so it’s supplementary.
This is my preferred approach to text field labelling and the use of placeholder text. I’ve used it and tested it on users and forms grow and ask for more complicated inputs the placeholder text becomes increasingly useful to users.
This approach also affords us the ability to increase the default colour of placeholder text so that it passes colour contrast guidelines, since the “Example:” prefix reduces the risk of placeholder text being confused for the value.
Let’s look at a second example field – the password field
We need to ask the user to create a password, the password must be at least 8 characters long and contain both letters and numbers.
Like before we will give the field a label, in this case, “Create password”, and associate the label to the field.
However, we need to inform the user that they need to meet certain password criteria and the label would likely be the wrong place to do that. I suppose what we are trying to do is give the user a “hint” about the expected field value.
So we use the placeholder attribute to add the text “Must be 8 characters long and contain letters and numbers”
And… that sucks! Terrible. The wrong choice was made here.
It sucks because:
- The field without the placeholder text wouldn’t be helpful
- The placeholder text on small field would overflow
- Whenever a user needs to refer back to the criteria, they must clear the field
- It excludes users of assistive technology
So despite this still being a hint it’s not a good use of the placeholder attribute for the above reasons.
The better solution here is to simply include the “hint” under the label and ensure it’s properly associated with the field for assistive technologies.
<label for=”field”>Create password</label> <p id=”hint”>Must be 8 characters long and contain letters and numbers</p> <input type=”password” id=”field” aria-describedby=”hint” />
Here the field is associated with the descriptive hint and the label. For users with assistive technology their tool can relay the description to them, for those who don’t rely on assistive tools can read the description directly below the label.
The hint is always visible and it follows standard text flow rules and will wrap onto new lines if available container space is limited.
I hope this article, despite it flogging a dead horse, is a helpful addition to the series and helps you make better use of the placeholder text or simply avoid using it altogether.
I have created a little social media shareable cheat sheet for placeholder text that you can refer back to from time to time.
Placeholder attribute rule card
- Do use for supplementary hints
- Do use for showing expected input
- Do change the placeholder style to contrast better
- Do prefix placeholder hints with “Example:”
- Don’t use for field labels
- Don’t use for critical information