Add placeholders to wp_login_form()

[ramiy]

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.

[ramiy]

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

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

[lukecavanagh]

40462.patch​ Applies cleanly.

[ramiy]

Related: #24324

[rel78]

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' );

[ramiy]

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.

[voldemortensen]

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

[jbpaul17]

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

[ramiy]

phpDocs alignment

[voldemortensen]

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

[johnbillion]

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

[ramiy]

Add phpDocs @since entry

[ramiy]

@johnbillion Done!

[ramiy]

Add @since entry to phpDocs

[voldemortensen]

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

[afercia]

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

[afercia]

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.

[ramiy]

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.

[afercia]

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

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.

[joedolson]

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.

[voldemortensen]

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

[ramiy]

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

add label classes

[afercia]

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.

[voldemortensen]

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.

[jbpaul17]

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

[afercia]

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.

[ramiy]

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.

[johnbillion]

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.

[s3w47m88]

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

[richardkentgates]

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

[afercia]

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.

[richardkentgates]

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

[pento]

Replying to 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.

[afercia]

Discussed again during today's accessibility meeting. As nothing new and no valid use cases emerged, we agreed to close this ticket again. Discussion can continue on closed tickets, valid use cases welcome.

[richardkentgates]

Support for placeholders is forthcoming. Since accessibility is the issue and placeholders add additional hinting or information, this advancement in common CMSs would support the goals of screen reading software by adding further assistance to its users. While the progress is currently with accessibility-specific markup, it shows intent and progress toward incorporating these technologies into screen readers. Considering that WordPress development on some issues can take years, I think it would be prudent to incorporate these changes now and allow native development of placeholders in WP core.

​https://github.com/nvaccess/nvda/issues/7004

​https://www.w3.org/TR/html-aria/

​https://www.blindbargains.com/bargains.php?m=17611

[afercia]

@richardkentgates that's not really the point being discussed here :) Placeholders are supported by assistive technologies. The real point is that the proposed usage is against the specification and harmful for usability and accessibility. So far, there are no valid use cases.

[richardkentgates]

Replying to afercia:

@richardkentgates that's not really the point being discussed here :) Placeholders are supported by assistive technologies. The real point is that the proposed usage is against the specification and harmful for usability and accessibility. So far, there are no valid use cases.

The intended use IS the use case. I don't understand the insistence that there are no valid uses for this.

I'll give you the use case I come across at least once a week...

Users enter (555) 555-5555 but the form is only designed to use 555-555-5555. Or so.and.so@… when the form only accepts soandso@…. Mc'Deal when it will only accept McDeal.

This assistance, or "hinting" or "additional information" is the intended purpose. That's why it's called a placeholder. It holds the place of actual data entry, by example.

I work with seniors every day that cannot understand why forms fail/error and the errors that report aren't always clear enough to help, if any errors actually report aside from a red border. As it is now, tomorrow, I have to drive 45 minutes to Milton Fl so I can help a client get their CPA logged in because they just can't figure ot out.

I think there is a lack of understanding here about how confusing the web still remains for some segments of the population. I don't agree with ignoring those users because a hanful of people have poor practices. Any and all aditional information to users is a good thing, even if some developers/designers choose to break their own websites.

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.

I think the logic behind the decision here is flawed. If this really is about accecibility and proper use, than maybe the solution should be for WP to manage the placeholder text based on predetermined criteria, rather than just tossing it out completely.

This is pretty much all I can say about this.

[sami.keijonen]

Users enter (555) 555-5555 but the form is only designed to use 555-555-5555

That's a good and proper use case for placeholder, but for phone number. In the login form there are only username/email and password fields.

For password field there is no use for placeholder. For username field placeholder email@example.org might work but we decided against it in yesterday a11y meeting.

• User knows own email. If not, placeholder would not help.
• You can also enter username which is hard to give hint via placeholder in the same time as email.
• All the reasons mentioned in this ticket.

[afercia]

@richardkentgates as also @sami.keijonen pointed out, this ticket is about the login form username / email and password fields. As largely discussed in the previous comments, which I'd recommend to read, seems pretty clear there's no valid use case for a suggestion or hint about the expected format of a password or username. Even the email case is arguable, as users already registered with their email and they're not required to follow an expected format to login.

[richardkentgates]

Replying to afercia:

@richardkentgates as also @sami.keijonen pointed out, this ticket is about the login form username / email and password fields. As largely discussed in the previous comments, which I'd recommend to read, seems pretty clear there's no valid use case for a suggestion or hint about the expected format of a password or username. Even the email case is arguable, as users already registered with their email and they're not required to follow an expected format to login.

1. I have to drive 45 minutes tomorrow to help a client's CPA log into WP.

2. I'm certain this thread will be referenced when arguing the use of placeholders throughout WP as you mentioned in another thread. Unless I should be making my case on every thread that mentions placeholders?

You stated...

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.

So while I realize this pertains to just log in, this thread will be used as a point of argument in the overall topic of placeholders at some point.

We disagree on a fundamental level about the role of an open source CMS. I feel it should cater to the management of the content and obviously, others feel it's a place to make a stand about design practices. The decision to leave this out of the code isn't just deciding best practices where the code of WP is concerned. It's a decision to tell others how to use their websites and I just don't think that is the role of WP. It's not very democratic, despite any insisting to the contrary.

Finding a way to cater to self-determined uses and accessibility at the same time would serve everyone's interest. I don't see a good argument to not go that direction, so it's not just accessibility at question here, it's preferences about design practice we are really arguing here.

---

Let me explain why this matters to me. The only reason I am even following this thread and a few others is that in two months time I am to begin work on a front-end registration and sign in form, complete with reCaptcha. The goal of this is consumer engagement with brands and giving users direct control over MailChimp subscriptions. The front-end sign in being the pertinent topic here.

As ridiculous as it might sound to a seasoned professional like yourself, I work with business owners who have little to no knowledge of the web on a regular basis, and even logging in is a challenge to some. As I've stated, I regularly spend time helping users just logging into a site.

Your arguments to leave this out simply ignores my professional experience and the experience of others who have a LOT of experience working with the general public, some who have accessibility issues in the form of understanding what they're even looking at. Whether you agree or not, there is an intended use for this. I don't work in a lab have expensive research papers. I work in the real world with real business owners every single day.

I'm unfollowing this thread as I don't expect any solution will be allowed and will need to be resolved via workarounds.

[s3w47m88]

@afercia you stated that you've not heard a actual use case that doesn't suggest one would remove or repeat the value of the Label. Particularly for the username and password fields. So here's a few:

Some WordPress websites allow the email address as the username, while others do not use the email address as the username. WordPress MultiSite doesn't allow email addresses without modification. The Placeholder value can show that so the user knows what to enter. On some sites my staff and I build we write out the email in the placeholder, other times we put "John Doe", other times we say "Username Here", etc... In other words, developers could put whatever they want and no one knows what will go there except the developer.

As for a password, having the * as the placeholder or descriptive text is a UI / UX choice made by the developer. I choose to use * in the password field for aesthetics even though it's not overtly helpful. Sometimes I put "12 Character Password Here" or "Password is Found In Your Email" because - like @richardkentgates mentioned I deal with surprisingly computer inept people.

What's important to acknowledge and respect here is that no one know what a developer is going to put in those values and to believe we do is an assumption and that is solely based on opinion - instead of confirmed facts.

The facts are that HTML supports placeholders for these fields, and the wp_login_form function exists to allow developers to customize the attributes that area associated with those fields. So, unless you or someone else can provide opinionated evidence that is based on verifiable facts about how accepting this patch is inconsistent with any programming standards it should be promptly accepted.

Most importantly, no one here has the authority to dictate whether or not placeholders are used, how they're used, or why their used. That is out of scope of this submitted patch and should not be discussed here.

And almost as important as that: there is a desire for this functionality by WordPress developers and it has literally NO consequence to anyone who opposes it. There has been NO evidence to support that this has any negative impact unless you're making an assumption about developer intent.

Can anyone tell me who, exactly, has the authority to approve to deny or accept this patch?

[pento]

@s3w47m88: Please don't re-open tickets that have been closed by a Core Committer. @afercia has said several times that the ticket can be re-opened at a later date, if we do decide to make this change. For the sake of our ticket management flows, however, this ticket should remain closed.

Replying to s3w47m88:

Can anyone tell me who, exactly, has the authority to approve to deny or accept this patch?

In this instance, @afercia is the person who makes this decision, as one of the Accessibility experts who works on WordPress Core. I can also make that decision, as one of the folks who looks at overall WordPress architecture. In this case, I agree with @afercia's assessment.

That said, I've also asked @dd32, one of the WordPress Lead Developers, to review this ticket and add his thoughts. I'll leave the ticket open pending his review.

[dd32]

After reviewing this ticket, I agree with @afercia and @pento on this one.

Put simply, placeholders are not a viable replacement for labels (although I admit are used as such in many forms, often badly) especially given the accessibility concerns raised.

Looking at 40462.5.patch​, given it requires custom code to be written and there's a bunch of workarounds posted here, there doesn't seem to be a good reason to even add support to core to me (which WordPress itself wouldn't use in the name of accessibility).

I personally find the ​WordCamp.org login screen to be the best example of how to provide extra contextual login details to end users, it does this by adding information prior to the login fields which explains what accounts to use. A short paragraph will always be more useful to an end-user than 2-3 words in a form field which disappear after focus..

[s3w47m88]

Thank you for that information @pento - will do.

[s3w47m88]

I am still very unclear about something here.

@pento @afercia and @dd32 each of you have repeatidly stated that this ticket's objective is to replace labels with placeholders.

And although it seems @ramiy indicated he does that, that's not what myself, (or from what I've read:) @richardkentgates @johnbillion or @voldemortensen are suggesting, asking or intending.

Do you guys just assume that if you allow developers to specify a Placeholder value it's going to lead to eliminating Label values? Or am I overlooking something with this ticket that is stating it is removing Labels and / or encouraging removing Labels?

Thank you.

[richardkentgates]

Replying to s3w47m88:

I am still very unclear about something here.

@pento @afercia and @dd32 each of you have repeatidly stated that this ticket's objective is to replace labels with placeholders.

And although it seems @ramiy indicated he does that, that's not what myself, (or from what I've read:) @richardkentgates @johnbillion or @voldemortensen are suggesting, asking or intending.

Do you guys just assume that if you allow developers to specify a Placeholder value it's going to lead to eliminating Label values? Or am I overlooking something with this ticket that is stating it is removing Labels and / or encouraging removing Labels?

Thank you.

Not worth pursuing.

I am new to the WordPress Codex but from what I can tell, I can use wp_authenticate() to submit my own forms. If that isn't the correct function to call, please advise.

[afercia]

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.

[olligranlund]

I came across this ticket when looking for ways to add placeholder texts to the login form. I feel that the original proposal is valid and should be implemented. I see WordPress as a very flexible platform for creating all kinds of sites and services, but not implementing this feature will probably end up with people doing workarounds, which is even worse. If someone really wants to use placeholders, there's always a way, but that doesn't mean that it should be "hard".

You can really easily make really bad sites as a WordPress developer from a accessibility perspective. You have already full access to the code and you can either take accessibility in account or not. As someone who has worked in several agencies, there's always a rush with projects and we are cutting corners to produce something viable in time. This is one thing that slows us down since we need to look for alternative solutions.

I feel that WordPress should not limit the HTML-syntax with disallowing placeholders. If one wants to have the placeholders, they will eventually get them in one way or another. For accessibility concerns, we create special workarounds so that users with dissabilities can grasp the information from websites in a similar way as normal users. Why is it then forbidden to help the normal user with a placeholder as a visual hint?

Sure there is a risk that the labels will be unused in favor of placeholder, but that is a decision that the developer has made. That decision is also affected in Google SEO and is alerted about in different a11y-plugins like Wave or Axe. One using the placeholder attribute should know about the downsides if they remove the label and face the consequences. People will circumvent this limitation until you let users add it in the right way. Who knows, maybe a11y-tools will at some point perceive the placeholder values as a good thing, but certainly, it's never going to be a negative one alone.