The Problem with Using Placeholder Attributes
I am not the first person to write about the accessibility issues of placeholders, but I keep seeing them pop up in different projects. It is not uncommon to see a design that looks like the following:
An input field, where the only way to discern its purpose of the input is through the placeholder. The code for this input field would look something like this (I’ve intentionally left out the CSS):
<input placeholer="Email (eg. name@domain.com)">
Simple, elegant and concise. Right?. Well, yeah it is, but is also fairly inaccessible. The simplicity of this pattern makes it very attractive, but most developers and designers fail to consider the accessibility implications.
What does WCAG say?
Using placeholders as labels for inputs is quite common, but often create accessibility barriers. There are actually multiple success criteria failures in using the example demonstrated above.
These include:
1.4.3 Contrast (Minimum)
This criterion ensures that the color of text meets a certain contrast ratio. Unfortunately, the default contrast for placeholders in most browsers does not meet the minimum required contrast ratio of 4.5:1 for regular text. In fact, placeholders are explicitly mentioned in the success criterion text:
You could of course change the color of the placeholders using CSS:
input::placeholder { color: #000; }
If you choose to use placeholders in your website, this is a must to meet the 1.4.3 Contrast (Minimum) criterion. But this is not enough to create accessible inputs.
3.3.2 Labels or Instructions
This criterion ensures that all inputs have labels or instructions to help identify the purpose of the input field.
Using a placeholder might not actually be a failure of 3.3.2 Labels or Instructions, since it does not mention that the text must always be visible. But, the fact remains that placeholder text is hidden as the user inputs information.
This might not be a big problem in the example of an email input, but can be a significant barrier when entering exact data formats or long text.
Imagine that you are presented with a field to input your phone number, but it must be in a very particular format, including spaces and dashes. The issue is that as you start typing, the example input disappears. Wait… where should the dash go, was it after the second or third digit? This forces you to clear the input field to make the placeholder visible again. This becomes an even larger difficulty for users with short term memory disabilities, as they might have to do this several times, or even fail to enter the information at all.
4.1.2 Name, Role, Value
This success criterion ensures that an accessible name and role can be determined for all interactive components.
How can we make placeholders accessible?
My recommendation is to not use the placeholder attribute at all. Placing any text inside a placeholder creates a problem where information becomes hidden from the user. The more accessible solution is to have a static label above or next to the input element.
Conclusion
In conclusion, while placeholders may seem like a simple and elegant solution for input fields, they pose significant accessibility challenges. It's crucial to prioritize accessibility by avoiding the use of placeholders as labels. Instead, opt for static labels that remain visible as users enter text. If placeholders must be used, ensure they meet contrast requirements and are supplemented with accessible names. By adopting these practices, we can create more inclusive and user-friendly web experiences for everyone.
Thank you for reading!