[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
------------------------------------+--------------------------------------

Comment (by pento):

 Replying to [comment:37 afercia]:
 > 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

 This is a good summary of the issue at hand, and I'm inclined to agree we
 shouldn't add placeholders here.

 I have no problem with WordPress being opinionated about what markup
 practices it supports: just because something is valid HTML doesn't mean
 we need to provide APIs to generate that HTML. This isn't about "not
 supporting the spec", it's about providing particular functionality based
 on best practices. For example, we don't provide buttons in the editor to
 add `<i>` and `<b>` tags, even though they're valid HTML, best practice is
 that they're not semantic, so generally shouldn't be used.

 We can leave this ticket open pending the Accessibility meeting, but if
 there's nothing new to report after that, it should be closed.

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