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. 1.4.3 Contrast (Minimum)

2. 3.3.2 Labels or Instructions

3. 4.1.2 Name, Role, Value

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:

This Success Criterion applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus.

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.

The key here is the accessible name. It is the name that is presented to assistive technology, i.e., the name that screen readers announce. For input fields, this is often the determined by <label> element. Notably, the placeholder attribute does not set the accessible name.

This means that if an input only has a placeholder element, and lacks a <label> or way to set the accessible name, the input will fail this success criterion.

How can we make placeholders accessible?

As I’ve explained, placeholders introduce various accessibility issues that will cause WCAG failures. But, the question is: “Can we even make placeholders accessible?”. Well, we can make them pass WCAG by upping the contrast and including accessible names using the <label> element, aria-label or aria-labelledby, but the issue where the text disappears as we type remain.

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.

If you want a look where the label is placed in the middle of the input field, use an approach like Material Design, where the label moves above the input field when focused.

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!