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

[afercia]

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:

[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:

​https://www.w3.org/TR/html51/sec-forms.html#the-placeholder-attribute

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

[joedolson]

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.

[afercia]

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! 🙂

[afercia]

New on Smashing Magazine, a nice recap:

Don’t Use The Placeholder Attribute
​https://www.smashingmagazine.com/2018/06/placeholder-attribute/

[afercia]

Update: in the latest ​HTML Accessibility API Mappings Editor's Draft (14 February 2019), the use of HTML placeholder attribute content as a fallback source of accessible name has been updated to reflect browser implementations. This point, previously removed, has been reintroduced:

3. Otherwise if the control has a placeholder attribute, use its value to provide an accessible name.

Still a draft though, pending final approval.

References:

• ​https://twitter.com/stevefaulkner/status/1096359374367440896
• previously: ​https://www.w3.org/TR/2019/WD-html-aam-1.0-20190124/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

[afercia]

Important note from Steve Faulkner: ​https://codepen.io/stevef/post/placeholder-the-piss-take-label

The reasons why use of the placeholder attribute as the only means of providing a user readable prompt for a form control is deficient UX, are voluminous.

See: ​W3C research on placeholders.

I first wrote about ​placeholder back in 2011, and included ​a note, ​later a warning, about its use in the dear superseded HTML5 specification in 2014.

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 controls 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.

placeholder as the only visible label for a control that requires user input fails ​Success Criterion 3.3.2 Labels or Instructions

WHY?
At the time of user input there is no visible label, the input purpose is mystery meat.

The entire post on codepen is a very recommended reading.

[afercia]

In 46418:

Accessibility: Media: Improve the search media field labelling.

Visible <label> elements benefit all users. The placeholder attribute should not be used as a replacement for visible labels.
Instead, it's supposed to be used only for a short hint to aid users with data entry e.g. a sample value or a brief description of the expected format.

Screen readers may not announce a placeholder attribute at all. Other users may suffer from the lack of a visible label and a placeholder used as replacement, for example:

• users with cognitive disabilities may have trouble remembering what the filled field does
• speech recognition users cannot see the name they can speak to set focus on the field
• low-vision users with high text-size may not be able to see the whole placeholder even when it's visible, if its value is clipped by the edge of the input

Props anevins, audrasjb, karmatosed, azaozz, SergeyBiryukov, afercia.
See #40331.
Fixes #47138.

[valentinbora]

@afercia do we need further audit here or are we all covered?

[afercia]

@valentinbora this is marked as an a11y-task meaning it's a large issue that will span across several releases to be fully addressed. It requires education first, and gathering consensus from other teams starting with the design team :) Not something that can be realistically done for 5.4.

[46418] addressed only a small part. There's still lot to do.

[valentinbora]

@afercia thanks for the feedback. Would you like to take Ownership of the ticket?

[joedolson]

After a quick scour for placeholders, I find a few occurrences:

• Search fields in add new plugins, search installed plugins, and media library in grid view
• The link UI in the classic editor/visual view
• Several in the customizer: search menu items, add new page/post, search widgets, search themes
• Examples in themes & the general search template, which I don't think we should change
• Examples in media-template.php. I'm not sure how those are being used, however. They start at ​https://github.com/WordPress/wordpress-develop/blob/0ac7b38407a880ce350616d8f1de9a14b178d1ab/src/wp-includes/media-template.php#L641

The other easily found instances of the placeholder attribute are legitimate. There may be more, but they may be harder to find.

Patches in progress.