WordPress.org

Make WordPress Core

Opened 11 months ago

Last modified 20 hours ago

#40462 reopened enhancement

Add placeholders to wp_login_form()

Reported by: ramiy Owned by: voldemortensen
Milestone: Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords: has-patch close
Focuses: accessibility, template Cc:

Description

Currently, if someone uses the wp_login_form() function in a theme or a plugin, and this someone wants to add placeholders to the input fields, he can't do that.

The attached patch adds placeholders to the wp_login_form() function using two new arguments. To maintain backwards compatibility, the placeholders are empty by default.

Attachments (6)

40462.patch (2.7 KB) - added by ramiy 11 months ago.
40462.2.patch (5.6 KB) - added by ramiy 6 months ago.
phpDocs alignment
40462.3.patch (5.8 KB) - added by ramiy 5 months ago.
Add phpDocs @since entry
40462.4.patch (5.8 KB) - added by ramiy 5 months ago.
Add @since entry to phpDocs
40462.4.2.patch (5.8 KB) - added by voldemortensen 5 months ago.
40462.5.patch (6.7 KB) - added by ramiy 5 months ago.
add label classes

Download all attachments as: .zip

Change History (46)

@ramiy
11 months ago

#1 @ramiy
11 months ago

  • Focuses template added
  • Keywords has-patch added

With this patch developers can add placeholders to their login forms:

wp_login_form( array(
	'placeholder_username' => __( 'Your username...' ),
	'placeholder_password' => __( 'Your password...' )
) );

#3 @ramiy
10 months ago

Related: #24324

#4 @rel78
10 months ago

It can be a great fix for the login form!
I found myself more than once using JS to modify the form,
when the client delivered a design for the form with placeholders..

$('#user_login').attr( 'placeholder', 'User Name' );
$('#user_pass').attr( 'placeholder', 'Password' );

#5 @ramiy
8 months ago

What problem does is solves?

Currently, plugin and theme developers they can set only custom labels. The placeholders are hardcoded. This change will add extra customization options for developers. Either to delete the placeholders entirely or to set custom placeholders.

#6 @ramiy
6 months ago

  • Component changed from General to Login and Registration

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


6 months ago

#8 @voldemortensen
6 months ago

  • Keywords commit added
  • Type changed from defect (bug) to enhancement

Patch looks good to me, the only nitpick would be a little alignment issue in the docblock.

#9 @jbpaul17
6 months ago

@voldemortensen are you ok with setting you as owner and milestone to 4.9 then?

@ramiy
6 months ago

phpDocs alignment

#10 @SergeyBiryukov
6 months ago

  • Milestone changed from Awaiting Review to 4.9

#11 @voldemortensen
6 months ago

@jbpaul17, sure. It's good to go as soon as someone can commit it.

#12 @voldemortensen
6 months ago

  • Owner set to voldemortensen
  • Status changed from new to accepted

#13 @johnbillion
5 months ago

This needs a @since entry in the function docblock for the new $args options.

@ramiy
5 months ago

Add phpDocs @since entry

#14 @ramiy
5 months ago

@johnbillion Done!

@ramiy
5 months ago

Add @since entry to phpDocs

#15 @voldemortensen
5 months ago

40462.4.2.patch fixed a very small nitpick in the @since entry. I think this is ready to go now.

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


5 months ago

#17 @afercia
5 months ago

  • Focuses accessibility added

#18 @afercia
5 months ago

Worth noting using placeholders as replacement for labels is a bad practice for accessibility. See #40331.

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


5 months ago

#20 follow-up: @afercia
5 months ago

Quoting from the discussion during latest accessibility team meeting on Slack:

@joedolson: Can we see any specific benefit to allowing it? As I see it, it will almost 100% be used to hide labels and use placeholders instead, but if there's a legitimate and beneficial use, I'd be willing to listen to it.

Worth considering WordPress shouldn't encourage accessibility bad practices, and using placeholders as replacement for labels is a bad practice for the reasons explained in #40331.

#21 in reply to: ↑ 20 @ramiy
5 months ago

Replying to afercia:

@joedolson: As I see it, it will almost 100% be used to hide labels and use placeholders instead

Not sure I agree with that direction of thinking. Core decisions should be based on more established arguments. I can easily contradict his claim - in most of my projects I use both labels and placeholders, like many of my colleagues.

Besides, as long as placeholders are valid HTML attributes you cannot tell developers not to use them in their projects.

From accessibility point of view we need to examine how WordPress Core uses placeholders, not how external developers might use them. I can tell you that WordPress core won't be affected from this patch because the default values are empty placeholders.

So why add those attributes? because wp_login_form() , like many other WP functions, is used not only by core but also by tens of thousands of external theme/plugins developers.

#22 @afercia
5 months ago

@ramiy have you read #40331 and all the references posted there? Plenty of more established arguments there.

as long as placeholders are valid HTML attributes you cannot tell developers not to use them in their projects.

RIght, they're valid. Then they should also be used in a valid way. Then, developers should also read the HTML51 specification to start with: https://www.w3.org/TR/html51/sec-forms.html#the-placeholder-attribute

According to the spec, placeholders must be exclusively used for "hins" about the expected format or data type to enter.

https://cldup.com/xgR83MonTx.png

In 99% of the cases, these proposed placeholders will be used as replacements for the labels and the labels will be hidden with CSS or something, and this is something WordPress shouldn't encourage.

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


5 months ago

#24 @joedolson
5 months ago

What kind of content would you imagine using in the placeholder field? I strongly feel I need an example of a valid method of using this before giving this serious consideration for inclusion in core.

The login form is very simple, and the existing labels clearly convey what content is needed in the field. I struggle to see a useful way that a placeholder can be used in this form, but I can clearly see - based on hundreds of form implementations I've seen in the past - that it absolutely *will* be used as a label substitute.

#25 @voldemortensen
5 months ago

I can think of one off the top of my head.

It would be helpful to have the placeholder yourusername@companyname.com for places that require specific email address domains (such as corporate intranet sites).

#26 @ramiy
5 months ago

@joedolson If we concern placeholder will be used as a label substitute, we can add two more $arg to control the label class attribute, this way developers can "hide" the label with screen-reader-text class but kipping them visible for screen readers.

wp_login_form( array(
        'label_username'       => __( 'Email Address' ),
        'label_password'       => __( 'Password' ),
        'label_class_username' => 'screen-reader-text',
        'label_class_password' => 'screen-reader-text',
        'placeholder_username' => __( 'Your username...' ),
        'placeholder_password' => __( 'Your password...' )
) );

Also, we can publish a post in https://make.wordpress.org/accessibility/ talking about "Accessibility best practices when using login forms", describing how to "safely" replace labels with placeholders using screen-reader-text class. It's an educational approach.

@ramiy
5 months ago

add label classes

#27 @afercia
5 months ago

  • Keywords close added; commit removed

It would be helpful to have the placeholder yourusername@… for places that require specific email address domains (such as corporate intranet sites).

Yep, I'd say that's one of the few (maybe only?) correct usage cases of a placeholder attribute in a username/email login form. I'd argue the password field instead can't have a placeholder as providing a sample value or the expected format would be questionable for security reasons.

this way developers can "hide" the label with screen-reader-text class but kipping them visible for screen readers.

@ramly <label> elements are not just for screen reader users. Hiding them, even if only visually, defeats the purpose of properly labeling form fields and it is clear in this case the placeholder will be used as a visual replacement.

describing how to "safely" replace labels with placeholders using screen-reader-text class. It's an educational approach.

there's no "safe" way for the reasons explained above. Labels benefit also sighted users. Instead of educating developers, in this case we should educate users and customers to explain them why they should not hide labels.

WordPress shouldn't encourage bad accessibility practices. For this reason, I'd propose to close this ticket as "wontfix", also considering there's a pending effort to review all the placeholders used in core, see #40331.

#28 @voldemortensen
5 months ago

Going on the record to say I disagree with closing this ticket.

I'd argue the password field instead can't have a placeholder as providing a sample value or the expected format would be questionable for security reasons.

This is a valid point.

I would still like to see a placeholder for the username/email field.

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


5 months ago

#30 @jbpaul17
5 months ago

  • Milestone changed from 4.9 to Future Release

Punting this to Future Release per the 4.9 bug scrub earlier today.

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


5 weeks ago

#32 @afercia
5 weeks ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from accepted to closed

THere;s no consensus as the suggested use of the placeholder attribute is against the spec and harmful for accessibility. CLosing for now. Discussion can continue on closed tickets.

#33 @ramiy
5 weeks ago

Your intentions are good, you are trying to make the platform accessible for users using screen-readers. But on the way you are hurting regular users, those who do use placeholders.

Yes, removing placeholders can increase accessible. But from a user experience point of view.

#34 @johnbillion
4 weeks ago

Most UX research shows that placeholders are detrimental to usability, even when they're used in conjunction with labels. Nielsen's article on placeholders covers it well.

#35 @s3w47m88
36 hours ago

  • Keywords close removed
  • Resolution wontfix deleted
  • Status changed from closed to reopened

@afercia

Allowing WordPress developers to pass an argument that is officially supported by HTML is not encouraging bad practices. However, not accepting this patch is preventing the proper use of HTML Placeholders. It has already encouraged developers to create Plugins that overwrite, filter and circumvent this core function and, even worse, use JavaScript. Both of which are bad practices.

#36 @richardkentgates
24 hours ago

@johnbillion The article you posted has no actual research citation. It's a set of well-articulated opinions. I have to agree that it is not the mandate of WordPress developers to dictate web standards to the online community, for designers, developers, or end-users. People with far more experience, real research, and educations have been making decisions that have continued to push the web forward, including usability.

Since following a few threads for core, I am noticing a worrisome trend of this dictatory attitude where web standards are concerned. I think if WordPress developers, that have so much power over the web, are going to engage in directing what they see as acceptable standards, they should become part of the governing body W3C, and put their ideas up for peer review, debate, and scrutiny. Otherwise, this dictation of standards is not in line with the democratic process that has made the internet so useful for so many.

Placeholders have their place. They are an efficient use of screen space which allows for more information in a smaller space, which can be a big help. And as @s3w47m88 pointed out, ignoring commonly used HTML practices will only lead to hacks to get it done, which compromises the end-user experience far more, not to mention the integrity of core or it's intended usage.

I am waiting on the upcoming changes to this area of WP myself so I can write a plugin for front-side(widget) login/registration with reCaptcha. I will certainly be using placeholders, with or without WP core agreement.

Last edited 24 hours ago by richardkentgates (previous) (diff)

#37 follow-up: @afercia
21 hours ago

  • Keywords close added

Thanks for bringing in new contributions to the discussion. As said previously, it's not uncommon to continue the discussion on closed tickets, there's no need to reopen them.

I'd encourage everyone to read again the HTML specification and better understand the underlying problem. I'd also suggest to have a look at the resources linked in the ticket #40331 mentioned a few times in the previous comments.

Here's what the current specification states: https://www.w3.org/TR/html52/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.

So, the only valid use for a placeholder is to provide a sample value or a brief description of the expected format.

Think, for example, at a birth date field or a phone number field where the placeholder suggests the expected date or number format, or a short phrase that suggests "enter the color value in RGB format".

Instead, the proposed patch purpose is to use the placeholders as replacement for the labels, see comment:1 with the code example.

Quoting from a previous comment from Joe Dolson:

As I see it, it will almost 100% be used to hide labels and use placeholders instead, but if there's a legitimate and beneficial use, I'd be willing to listen to it.

So the real question is: is there any valid use for placeholders in this specific case?

For the password field: providing a "sample value" or "description of the expected format" wouldn't be so appropriate, I guess everyone agrees on this?

For the username/email field (assuming it would be possible to differentiate when users are going to enter a username or an email):

  • username: providing a "sample value" or "description of the expected format" of a username would be a bit pointless
  • email: a valid usage could be something like person@example.org but, again, it would be a bit pointless

@s3w47m88 for the reasons explained above I can't think of a valid use case for placeholders in the login form, but if you have any example of a proper use please do feel free to share it.

@richardkentgates

Placeholders have their place. They are an efficient use of screen space which allows for more information in a smaller space

Seems the W3C disagrees :) Placeholders are not meant to be used for visual purposes.

I think if WordPress developers, that have so much power over the web, are going to engage in directing what they see as acceptable standards, they should become part of the governing body W3C, and put their ideas up for peer review, debate, and scrutiny. Otherwise, this dictation of standards is not in line with the democratic process that has made the internet so useful for so many.

I'm sorry to hear your concerns about a "dictatory attitude". As I see it, there's no such a thing as "WordPress developers" as opposed to the rest of the world :) Anyone can contribute to WordPress and I'd encourage you to do so, starting from https://make.wordpress.org/ you can participate to the various teams activity, follow the meetings, and propose any improvement.

This issue has been discussed a few times during the accessibility team meetings, they happen on Mondays at 17:00 UTC in the Slack #accessibility channel. All meetings are public and everyone can participate.

In a large open-source project like WordPress, proposals get discussed and need to gather some consensus. At the end, it's all about making decisions. I kindly disagree with you and I don't see any attempt to "direct what they see as acceptable standards". The decision made here just follows the existing W3C standards, which are already subject to public debate, peer review, etc. Thus, I'm not sure I fully understand your point.

Worth also considering WordPress aims to be a semantic publishing platform, and aims to meet web standards and best practices. Personally I strongly believe WordPress has a huge educational responsibility and it should always aim to show best practices and educate to use them.

Trying to summarize:

  • there's no apparent valid use case for the proposed change (valid use case examples welcome)
  • in almost 100% of the cases the proposed change would be used to hide the labels and use placeholders as replacements: this is against the HTML specification and creates usability and accessibility barriers
  • many users benefit from visible labels, it's not just about screen readers
  • although it's a common practice, using placeholders as replacement for labels is just a bad practice: WordPress should educate designers and developers to not do that
  • this proposal was discussed at length by the accessibility team and good argumentations were provided against it

Considering all this, I'd be inclined to close again this ticket but, to encourage participation, I'll propose to discuss it again in the next accessibility meeting which is going to happen on Monday 26th at 17:00 UTC in the Slack #accessibility channel.

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


21 hours ago

This ticket was mentioned in Slack in #accessibility-docs by sami.keijonen. View the logs.


20 hours ago

#40 in reply to: ↑ 37 @richardkentgates
20 hours ago

Replying to afercia:

There is plenty disagreement to go around but placeholders have enough use cases and agreement to make it into the spec. Even in the below-linked page, there is the discussion on how to address the usage and Accessibilitiy without the arbitrary removal of placeholders. Nobody is saying this is not a complex issue, but simply doubling down on the argument to arbitrarily dictate this issue for everyone that uses WP and to say "we won't support the spec" is still no more legitimate following your reply. The argument seems to be to simply point out that some developers/designers misuse the tools at hand so the tools should be removed/denied. That is enough argument to remove the entire internet.

https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Placeholder_Research

Last edited 20 hours ago by richardkentgates (previous) (diff)
Note: See TracTickets for help on using tickets.