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
• email
• 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

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

Preview

Password

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

Preview

Password

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.