Make WordPress Core

Opened 7 years ago

Closed 3 days ago

#40331 closed task (blessed) (fixed)

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

Reported by: afercia's profile afercia Owned by: joedolson's profile joedolson
Milestone: 6.6 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots a11y-task has-patch commit
Focuses: ui, accessibility Cc:

Description (last modified by 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:

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:

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

Attachments (22)

40331.themes.diff (8.7 KB) - added by joedolson 4 months ago.
Patch removing placeholders in customizer theme searches
40331-themes-customizer.png (52.4 KB) - added by joedolson 4 months ago.
Before and after screenshots
40311-customizer.png (40.4 KB) - added by joedolson 4 months ago.
Before and after of customizer widget/menu/homepage
40331.customizer.diff (9.3 KB) - added by joedolson 4 months ago.
Customizer patch with corrected encoding
40331.media-plugins.diff (7.1 KB) - added by joedolson 4 months ago.
Patch removing placeholders in media library and plugins search
40311-media-plugins.png (41.8 KB) - added by joedolson 4 months ago.
Screenshots for media/plugins
40331-wp-link-url.diff (1.3 KB) - added by joedolson 4 months ago.
Remove placeholder in classic visual editing link editor
wp-link-url-before.png (4.1 KB) - added by joedolson 4 months ago.
Link editor before
wp-link-url.png (9.4 KB) - added by joedolson 4 months ago.
LInk editor after
40331.combined.diff (27.1 KB) - added by joedolson 4 months ago.
Combined diff for easier testing; fixes issues with link modal
40331.combined.2.diff (27.5 KB) - added by joedolson 4 months ago.
Completes fixes for link input modal
40331.combined.2.fixed.diff (27.6 KB) - added by rcreators 4 months ago.
Fixed error with patch file. Patch file was missing slace before src directory for all the file.
homepage-setting.png (24.1 KB) - added by rcreators 4 months ago.
I have tested the patch. Everything seems to be working. There is one point which needs to be updated on the Customiser -> Homepage setting. This New page title text should be hidden by default and only be visible when add new button is clicked.
40331.3.diff (26.6 KB) - added by sabernhardt 4 months ago.
40331.4.diff (28.4 KB) - added by joedolson 5 weeks ago.
Updated patch
click search installed themes.png (31.4 KB) - added by afercia 5 weeks ago.
Issuing the voice command 'click search installed themes' Voice Control shows two numbers
40331.5.diff (5.3 KB) - added by joedolson 5 weeks ago.
Theme search placeholder
40331.6.diff (5.2 KB) - added by joedolson 5 days ago.
Updated patch for themes search fields
before-after-40331.6.png (378.1 KB) - added by joedolson 5 days ago.
After & Before screenshots for 40331.6
40331.7.diff (5.8 KB) - added by joedolson 3 days ago.
Updated patch incorporating feedback
40331-add-theme-sub1024.png (22.6 KB) - added by joedolson 3 days ago.
40331-add-theme-sub600.png (26.5 KB) - added by joedolson 3 days ago.

Download all attachments as: .zip

Change History (83)

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


7 years ago

#2 @joedolson
7 years 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
7 years ago

Important news: The placeholder and aria-placeholder attributes are going to don't 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! 🙂

Version 0, edited 7 years ago by afercia (next)

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


7 years ago

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


6 years ago

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


6 years ago

#7 @afercia
6 years ago

New on Smashing Magazine, a nice recap:

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

This ticket was mentioned in Slack in #meta-tracdev by ocean90. View the logs.


5 years ago

#9 @afercia
5 years ago

  • Description modified (diff)

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:

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

Still a draft though, pending final approval.

References:

#10 @afercia
5 years ago

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.

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


5 years ago

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


5 years ago

#13 @afercia
5 years ago

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.

#14 @valentinbora
4 years ago

  • Keywords close added
  • Milestone changed from Future Release to 5.4
  • Owner set to valentinbora
  • Status changed from new to accepted

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

#15 @afercia
4 years ago

  • Keywords close removed
  • Milestone changed from 5.4 to Future Release

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

#16 @valentinbora
4 years ago

  • Owner valentinbora deleted
  • Status changed from accepted to assigned

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

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


4 years ago

#18 @joedolson
8 months ago

  • Milestone changed from Future Release to 6.5
  • Owner set to joedolson
  • Status changed from assigned to accepted

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


8 months ago

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


8 months ago

#21 @joedolson
8 months ago

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

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.

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


4 months ago

@joedolson
4 months ago

Patch removing placeholders in customizer theme searches

@joedolson
4 months ago

Before and after screenshots

@joedolson
4 months ago

Before and after of customizer widget/menu/homepage

@joedolson
4 months ago

Customizer patch with corrected encoding

@joedolson
4 months ago

Patch removing placeholders in media library and plugins search

@joedolson
4 months ago

Screenshots for media/plugins

@joedolson
4 months ago

Remove placeholder in classic visual editing link editor

@joedolson
4 months ago

Link editor before

@joedolson
4 months ago

LInk editor after

#23 @joedolson
4 months ago

  • Keywords has-patch added

Added patches & screenshots for the different cases identified where placeholders were still in use.

#24 @afercia
4 months ago

  • Keywords needs-refresh added

I tried to test the patches but they don't apply cleanly for me.
Going through the code changes, they all make sense to me and I'm all for these changes.

I noticed only a few things to check in the `40331-wp-link-url.diff patch:

  • Missing ID on the input field.
  • Not sure about the CSS rule for the selector div.mce-flow-layout-item > div which seems to break the TinyMCE breadcrumb at the bottom of the editor.
  • Anyways, I think we should use align-items: flex-end instead of align-items: end?

@joedolson
4 months ago

Combined diff for easier testing; fixes issues with link modal

#25 @joedolson
4 months ago

Note: the combined patch needs a little work, still, but I wanted to get an update posted this morning.

Adding a label in the link modal broke the modal selectors, which were all based on firstChild relationships; I think I'm still missing one in the above patch, but will take care of that this afternoon.

@joedolson
4 months ago

Completes fixes for link input modal

#26 @joedolson
4 months ago

  • Keywords needs-testing added; needs-refresh removed

#27 @huzaifaalmesbah
4 months ago

I try to test patch 40331.combined.2.diff but i can't test i get failed message.

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


4 months ago

@rcreators
4 months ago

Fixed error with patch file. Patch file was missing slace before src directory for all the file.

#29 @joedolson
4 months ago

This patch thing is presumably an environment problem that's pretty recent; because I can't apply the fixed patch. Not a concern, since I can apply my own version, but it's odd.

What's your environment, @rcreators? Are you applying into git or svn? Which command are you using to apply?

#30 @rcreators
4 months ago

Hello @joedolson, I am using sublime and sublime merge for git stuff. Can directly create patch and apply patch with UI. Never used command. But because of that I can see the errors.

My environment is WordPress-develop trunk branch. For checking this patch, I also made new branch. You can check it here: https://github.com/Rcreators/wordpress-develop/tree/%2340331

Let me know if above have any issue.

@rcreators
4 months ago

I have tested the patch. Everything seems to be working. There is one point which needs to be updated on the Customiser -> Homepage setting. This New page title text should be hidden by default and only be visible when add new button is clicked.

#31 @joedolson
4 months ago

I can't reproduce that issue @rcreators; can you double check? That should be getting hidden by JS at https://github.com/Rcreators/wordpress-develop/blob/%2340331/src/js/_enqueues/wp/customize/controls.js#L3742, and the label should be inside that wrapper, and is on https://github.com/Rcreators/wordpress-develop/blob/%2340331/src/wp-includes/class-wp-customize-control.php#L638.

The code in your repo matches mine, but your results aren't; if you can just verify that the JS changes are applied in your test that would be great.

#32 @rcreators
4 months ago

Hello @joedolson, Sorry for the confusion. My bad. I didn't check that the js file needs to be built again from the src. So it was an old js file loading. I build it from the new patch source and it works fine.

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


4 months ago

#34 @joedolson
4 months ago

  • Keywords commit added; needs-testing removed

@sabernhardt
4 months ago

#35 @sabernhardt
4 months ago

  • Keywords commit removed
  • Milestone changed from 6.5 to 6.6

I was not able to test all of the fields, but I made a few edits:

  • Removed empty vertical-align from .themes-filter-bar .wp-filter-search label (the label has middle alignment, which seems fine).
  • Moved the Customizer search icon's top: 6px from the 900px breakpoint to 782px, where the input changes height.
  • Removed the unit from 0px in the column-gap value from media.css.
  • Added the leading zero to column-gap for p.search-box.

It's also very late in the cycle to make so many changes.

Last edited 4 months ago by sabernhardt (previous) (diff)

#36 @joedolson
4 months ago

Punting seems fine; there's a lot going on in here.

@joedolson
5 weeks ago

Updated patch

#37 @joedolson
5 weeks ago

Updated patch includes a number of points of polish.

  • Customizer Search themes
    • Desktop OK
    • Middle OK
    • Narrow OK
  • Customizer search org themes
    • Desktop OK
    • Middle - moved the 900px breakpoint on the customize preview header to 960px
    • Narrow OK
  • Customizer menu items search
    • Desktop OK
    • Middle OK
    • Narrow - icon missing; removed top position adjustment, moved location of clear button, adjust results position.
  • Customizer classic widgets search
    • Desktop OK
    • Middle - Adjust search results position.
    • Narrow - Adjust search results position.
  • Customizer homepage/posts page setting
    • Desktop OK
    • Middle OK
    • Narrow - Tweaked line height on input label.
  • Plugins search
    • Desktop OK
    • Middle OK
    • Narrow - Make search input on add plugins full width below 600px for better layout.
  • Media search
    • Desktop OK
    • Middle OK
    • Narrow OK
  • Classic link editor search
    • Desktop OK
    • Middle OK
    • Narrow OK

#38 @joedolson
5 weeks ago

In my opinion, this should go in soon. It touches a lot of points. It's mostly just CSS work, and if there are issues they can be patched, but more eyes on it will be the most helpful thing.

#39 @afercia
5 weeks ago

I tested 40331.4.diff and it looks good to me.
The changes are clear and well illustrated with screenshots.

I agree with @joedolson this should go in soon so that any potential issue can be caught in time and patched.

I noticed a couple long standing issues that are surfaced by this patch. I'd like to leave others to decide whether they should be addressed in this patch or separately. See following comment.

#40 @afercia
5 weeks ago

Couple long standing issues that would need a decision:

Clicking the Search Menu Items label doesn't do anything

Making the 'Search Menu Items' label visible in the Customizer surfaces a problem with the JavaScript of the accordions. To reproduce:

  • Go to Customize > Menus > edit a menu > click 'Add Items'.
  • The search panel opens.
  • Click the 'Search Menu Items' label and observe focus is not set to the search input label.
  • Expected: focus to be set on the input when clicking the visible label. That's native browser behavior.

I tracked down this issue to the fact the menu item search is wrapped within the HTML markup that is meant to be used for accordions. There is a container element with CSS class accordion-container and a children with CSS class accordion-section-title that contains the label and the input. The click event callback runs when clicking anything inside accordion-section-title and it calls preventDefault() thus preventing the native behavior of a clicked label element. See the related code.

I'm not sure why the menu items search is wrapped within elements with the CSS classes meant for accordions. The widgets search markup, which is very similar, doesn't use those classes.

It is worth noting that the CSS class accordion-section-title is meant to be used only on an element that contains an accordion title. Any other usage is incorrect so this appears to be a bug that originates from [32806] / #32576.

As said, this bug is unrelated to the patch proposed on this ticket but it is surfaced by it. It would be worth investigating the best path to fix it.

Placeholders that use the same text of a visually hidden label

I'm not sure why other placeholder aren't addressed, for example Search installed themes... in wp-admin/themes.php. This input field has:

  • A visually hidden label: 'Search Installed Themes'
  • A placeholder attribute with text that almost matches the label: 'Search installed themes...'

Are we going to allow this pattern? While that may work for screen reader users, it isn't ideal for speech recognition software users. Testing with Safari and Voice Control, when issuing a voice command like 'click search installed themes', Voice Control will show two numbers on the screen, because both the label and the input use the same text. The expected behavior is the input field to receive focus. See attached screenshot.
While this may be a Voice Control glitch, I'd tend to think we should better consider this pattern.

@afercia
5 weeks ago

Issuing the voice command 'click search installed themes' Voice Control shows two numbers

#41 @joedolson
5 weeks ago

Thanks @afercia!

1) Accordion section title. I agree; this should be made more equivalent to the widgets header. I had noticed that those were different, but just didn't tackle it. But I hadn't noticed that it was causing that extra problem with the label not being clickable, which is worth resolving.

2) I'd intended to remove duplicate placeholders in this patch; I presumably missed that one. Is that the only still present patch you're seeing, or are you just using it as an example?

This patch has gone through a lot of iterations...

Number 2 is a minor tweak that can easily be done in this patch; the first I'm not as sure about, as there's a lot of stuff tied up in that class that could require a lot of tweaking. But I'll try it and see what happens. If it causes complicated problems, I'll create a follow-up ticket to deal with it separately after this is committed.

#42 @afercia
5 weeks ago

Is that the only still present patch you're seeing, or are you just using it as an example?

I'm using it as an example.

This patch has gone through a lot of iterations...

Yes, I'd agree to commit the patch as is now. This ticket could also be used as a task and and use more commits.

#44 @joedolson
5 weeks ago

  • Keywords commit added

Per comments from @afercia, I'm going to commit this patch as is. The search installed themes input is one I missed, but I don't think there's a benefit to making this commit more complicated than it already is; I'll just re-open this ticket as a task after the commit.

This ticket was mentioned in PR #6551 on WordPress/wordpress-develop by @joedolson.


5 weeks ago
#45

  • Keywords commit removed

#46 @joedolson
5 weeks ago

  • Keywords commit added

Remarking for commit.

#47 @joedolson
5 weeks ago

In 58146:

Administration: A11y: Replace placeholders with visible labels.

Add visible labels to inputs that are using placeholder attributes as a substitute for visible labeling.

Labels added or made visible on the customizer theme search, customizer widget search, customizer menu item search, customizer new page UI, the search plugins screens, the media search screens, and the classic editor link inserter.

Props afercia, joedolson, rcreators, sabernhardt.
See #40331.

@joedolson commented on PR #6551:


5 weeks ago
#48

Fixed in [r58146]

#49 @joedolson
5 weeks ago

  • Type changed from defect (bug) to task (blessed)

Switching to a task to do follow-up commits on related issues cited by @afercia above.

@joedolson
5 weeks ago

Theme search placeholder

#50 @joedolson
5 weeks ago

Uploaded patch handles the overlooked placeholder in the Themes search interface.

Last edited 5 weeks ago by joedolson (previous) (diff)

#51 @joedolson
5 weeks ago

  • Keywords commit removed

#52 @sabernhardt
7 days ago

#61389 has a separate report about the theme search's margin (as it is now).

#53 @hmbashar
7 days ago

  • Keywords needs-testing added

#54 @joedolson
7 days ago

Yes, I was already aware of that oversight from the original commit. Wasn't aware of the open ticket, however.

@joedolson
5 days ago

Updated patch for themes search fields

@joedolson
5 days ago

After & Before screenshots for 40331.6

#55 @joedolson
5 days ago

This adds the label, but also makes the search installed themes input placement & wrappers match that used on other screens, improving overall search consistency.

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


5 days ago

#57 @rcreators
4 days ago

@joedolson Need some design refinement.

For Add New Theme
1) Below 1024, need to add some margin between label and field. https://prnt.sc/VGkvbJtMWL9Q

2) Below 600, Label and search field needs to be in separate line. Check plugin install search field.
Theme: https://prnt.sc/hdZxwidUmS_2
Plugin: https://prnt.sc/syR2aWlNhtET

For Theme page - looks good but can be improved with some margin as well. Plugin page is quite polished in this case as well. So can take as a reference.

@joedolson
3 days ago

Updated patch incorporating feedback

#58 @rcreators
3 days ago

@joedolson If you check this plugin screenshot https://prnt.sc/syR2aWlNhtET Lable and search field has some margins. That is the only thing missing in this patch. Once that done. We are good to commit this.

#60 @joedolson
3 days ago

  • Keywords commit added; needs-testing removed

#61 @joedolson
3 days ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 58405:

Administration: A11y: Add visible labels in theme UI.

Finish task to replace placeholders used for labels with visible label elements. Add label elements in theme browser and theme installation screen. Change position of search input to match other user interfaces in WordPress.

Also crediting all contributors to ticket #61389, which this also closes.

Props joedolson, rcreators, sabernhardt, balub, rejaulalomkhan, syamraj24, nazmul111, krupajnanda, huzaifaalmesbah, hmbashar, mdnesarmridha, colorful-tones, printsachen1.
Fixes #40331, #61389.

Note: See TracTickets for help on using tickets.