[wp-trac] [WordPress Trac] #40462: Add placeholders to wp_login_form()

[WordPress Trac]

#40462: Add placeholders to wp_login_form()
------------------------------------+--------------------------------------
 Reporter:  ramiy                   |       Owner:  voldemortensen
     Type:  enhancement             |      Status:  reopened
 Priority:  normal                  |   Milestone:
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch close         |     Focuses:  accessibility, template
------------------------------------+--------------------------------------
Changes (by afercia):

 * keywords:  has-patch => has-patch close


Comment:

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

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