[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:  closed
 Priority:  normal                  |   Milestone:
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:  wontfix
 Keywords:  has-patch               |     Focuses:  accessibility, template
------------------------------------+--------------------------------------
Changes (by afercia):

 * keywords:  has-patch 2nd-opinion close => has-patch
 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 > In this instance, @afercia is the person who makes this decision, as one
 of the Accessibility experts who works on WordPress Core.

 Just to clarify I'm the person who's commenting here, but this ticket has
 been discussed publicly during two accessibility team meetings and the
 decision was based on a large consensus.

 @s3w47m88 I'm not opposed to continue the conversation, if that happens
 with a respectful, relaxed tone and helps to clarify the issue to
 everyone. Most of your examples are not conforming, as they're not a
 "sample value or a brief description of the expected '''format'''" with
 the exception of the email but one could argue that a generic email
 example doesn't represent the user's email format which could be
 completely different.

 {{{
 "John Doe"
 "Username Here"
 "********"
 "12 Character Password Here"
 "Password is Found In Your Email"
 }}}


 None of those is an example of the expected format (we could debate on "12
 Character Password Here").

 > There has been NO evidence to support that this has any negative impact

 It has a big impact on the way assistive technologies report these fields
 to users, and the only guarantee to provide correct information to all
 users is to meet the specifications. I'd say it impacts also sighted
 users, as the information provided in a placeholder disappears as soon as
 you start typing.

 As @dd32 pointed out, when there's the need to provide lengthy login
 details to users, then probably the best way to do that is to put that
 info in plain text before the login form. Not certainly in the
 placeholders, since they have a different purpose.

 Any software is opinionated, and sometimes there's the need to make
 assumptions for the greater good. Worth reminding WordPress is already
 doing this in a lot of places, allowing only certain HTML elements,
 attributes, and sometimes also checking the attributes value.

 Overall I feel we're going in circles and all the argumentations have been
 clearly explained.

 As said, please don't re-open tickets that have been closed by a Core
 Committer especially when tickets have been largely discussed. Tickets
 statuses, keywords, tags. etc. are used to generate the Trac reports for
 managing and triaging tickets and they impact the tickets management flow.

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