Make WordPress Core

Opened 15 months ago

Last modified 4 months ago

#40331 new defect (bug)

The placeholder attribute should not be used as a replacement for a label

Reported by: afercia Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots a11y-task
Focuses: ui, accessibility Cc:


This is the second ticket in the a11y-task series, which aims to start a discussion and research on broad accessibility issues. See also #40330.

Across the WordPress admin, the placeholder attribute is used in an inconsistent way. Sometimes it's used properly, sometimes not. For example, this is a good usage because the form fields have a visible label and the placeholder clarifies the expected format:

https://cldup.com/G8zSR9UYzm.png [The "Post via email" section in the WordPress Writing Settings]

In other cases though, the placeholder attribute is used as a replacement for a label. While it's tempting for designers to use it this way, especially when screen real estate for a visible label is limited, this practice introduces accessibility (and usability) barriers and goes against the HTML5 specification.

Despite the fact labels and placeholders have distinct (and complementary) purposes, replacing labels with placeholders has become, unfortunately, a popular practice.

In the accessibility team we've discussed this issue a few times, and we'd like to propose to make an effort to change the current approach when using placeholders. Basically, the only use case when a placeholder used as a visual label can be considered acceptable, is when there's just one, simple, form field and its purpose is made very clear by the context. For example, a search field.

​WordPress aims to be as much accessible as possible, I'd say a good first step would be striving to conform to the WCAG and HTML5 specifications. One more good step would be avoiding to introduce new cases where the placeholder attribute is misused πŸ™‚ .

There are lots of resources online about the placeholder issue, so I'd prefer to keep this ticket description short and refer to them, starting with what the HTML5 specification says:


The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format. The placeholder attribute should not be used as a replacement for a label. For a longer hint or other advisory text, place the text next to the control.

And then, in a big red-bordered box:

Warning! Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control’s label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.

Other resources:

W3C Web Accessibility Tutorials ​https://www.w3.org/WAI/tutorials/forms/instructions/#placeholder-text

W3C WAI Wiki: Using @placeholder on input ​http://www.w3.org/WAI/GL/wiki/Using_@placeholder_on_input

LΓ©onie Watson: Using the HTML5 placeholder attribute ​http://tink.uk/using-the-html5-placeholder-attribute

The Paciello Group. HTML5 Accessibility Chops: the placeholder attribute ​http://www.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/

WebAIM: Creating Accessible Forms ​http://webaim.org/techniques/forms/advanced

Nielsen Norman Group. Placeholders in Form Fields Are Harmful ​http://www.nngroup.com/articles/form-design-placeholders/

Roger Johansson - 456 Berea Street. The HTML5 placeholder attribute is not a substitute for the label element ​http://www.456bereastreet.com/archive/201204/the_html5_placeholder_attribute_is_not_a_substitute_for_the_label_element/

Web Axe: Placeholder Attribute Is Not A Label! ​http://www.webaxe.org/placeholder-attribute-is-not-a-label/

Mobile Form Usability: Never Use Inline Labels ​https://baymard.com/blog/mobile-forms-avoid-inline-labels See the "Exceptions" paragraph

Change History (6)

This ticket was mentioned in ​Slack in #accessibility by afercia. ​View the logs.

15 months ago

#2 @joedolson
15 months ago

  • Milestone changed from Awaiting Review to Future Release

This is very important, and needs to be addressed. We're marking it as future release, and will work on the issues as time allows.

#3 @afercia
14 months ago

Important news: The placeholder and aria-placeholder attributes are going to not contribute any longer to the accessible name computation, so that's one more reason to don't use them as replacement for labels. It is not intended for that usage. ​https://twitter.com/stevefaulkner/status/854632033515122688 See also: ​https://github.com/w3c/html-aam/issues/87 ​https://w3c.github.io/html-aam/#att-placeholder ​https://bugzilla.mozilla.org/show_bug.cgi?id=1303429 ​https://bugs.chromium.org/p/chromium/issues/detail?id=713600 ​https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11729402/

This is more and more something that should be brought to every designers attention! πŸ™‚

Last edited 9 months ago by afercia (previous) (diff)

This ticket was mentioned in ​Slack in #core by afercia. ​View the logs.

9 months ago

This ticket was mentioned in ​Slack in #accessibility by afercia. ​View the logs.

5 months ago

This ticket was mentioned in ​Slack in #accessibility by afercia. ​View the logs.

4 months ago

Note: See TracTickets for help on using tickets.