[wp-trac] [WordPress Trac] #40331: The placeholder attribute should not be used as a replacement for a label

Sat Feb 16 11:53:20 UTC 2019

#40331: The placeholder attribute should not be used as a replacement for a label
---------------------------------------+--------------------------------
 Reporter:  afercia                    |       Owner:  (none)
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  Future Release
Component:  Administration             |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots a11y-task  |     Focuses:  ui, accessibility
---------------------------------------+--------------------------------

Old description:

> 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:
>
> [[Image(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.
>
> [https://make.wordpress.org/core/handbook/best-practices/coding-standards
> /accessibility-coding-standards/ 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

New description:

 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:

 [[Image(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.

 [https://make.wordpress.org/core/handbook/best-practices/coding-standards
 /accessibility-coding-standards/ 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

--

Comment (by afercia):

 Update: in the latest [https://w3c.github.io/html-aam/#input-type-text-
 input-type-password-input-type-search-input-type-tel-input-type-url-and-
 textarea-element 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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/40331#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform