Fix the placeholder for the post title field on the classic Edit Post screen

[azaozz]

This is actually a <label> element positioned on top of the <input> that we hide with a bit of js when the input field is not empty.

The problem is that when the user right-clicks on the placeholder text, the browser's context menu is "wrong", the browser shows the "general" menu instead of the "edit" menu, there is no Paste, Spellcheck, etc.

[azaozz]

Follow-up from ​https://wordpress.org/support/topic/cant-paste-text-into-title-box/.

Thinking this is a "left-over" from a long time ago when placeholders weren't working well in all browsers. We probably should just use a placeholder attribute and leave the <label> permanently hidden with the screen-reader-text class.

This may have some accessibility implications, so setting that focus.

[masummdar]

A possible fix to #47318

[masummdar]

Hi,
I have added a patch with https://core.trac.wordpress.org/attachment/ticket/47318/47318.diff. Hope this helps. I have tested on my local setup, but might need more testing.

This is my first contribution so (fingers crossed).

Thank you.

[afercia]

For some background: [44896] / #42390.

In that ticket, the initial idea was to use a native placeholder attribute. Considering backwards compatibility and the presence of the enter_title_here filter, the final decision was:

• Quick Press widget in the Dashboard: use visible <label> elements and a native placeholder attribute
• Post title: keep the JavaScript "prompt text" thing and make the text behave like a placeholder: the text now disappears only when typing something, while previously disappeared on focus. Hence, the right-click problem.

Definitely in favor of using a native placeholder attribute, if that's possible. The patch should ensure the enter_title_here filter still works.

[masummdar]

This could be a fix for the right click without touching current code for floating label.

[masummdar]

Thanks to @afercia for pointing out the resources.

As plugins are using enter_title_here filter and to keep supporting it we
can't but leave the floating label feature as it is for now. But it would be
great to use native placeholder.

So for now, we could fix the right click issue with CSS. I have added this to https://core.trac.wordpress.org/attachment/ticket/47318/47318-alt.diff .

[azaozz]

Looking at https://core.trac.wordpress.org/ticket/42390#comment:10 and the following two comments: unless I'm missing something thinking that on the Edit Post screen we can:

• Use $title_placeholder (after the filter) as a "real" placeholder on the text input field (needs esc_attr()), and as text for the <label>. That is pretty much how it works now.
• Leave the <label> permanently hidden with screen-reader-text. I.e. remove the js that adds and removes the class.

Alternatively we can change the text of the label to "Title", however seems that may not fit for some CPTs.

[afercia]

From an accessibility perspective, worth considering a couple things:

• Internet Explorer 11 still removes the placeholder on focus, which is not standard and a bit annoying. The current implementation makes the visual behavior consistent across browsers
• using the same value for the <label> element and the placeholder attribute would be necessary for speech recognition software users, as they need to know the input field name (given by the label) to be able to voice a command like Click Add Title. However, some screen readers may announce "Add Title" twice. ​This behavior is greatly inconsistent across different browser/screen reader combos. See a quick example in the screenshots below:

Firefox + NVDA

Chrome + NVDA

I'd tend to think the Internet Explorer 11 behavior is a minor concern. A bit more concerned about the value for the placeholder attribute and the double announcement. Worth also reminding this way to use placeholders is already a compromise for accessibility: placeholders shouldn't be used as visual replacement for labels, see #40331.

Ideally, for web standards and accessibility, the title field should just use a visible label element :)

[audrasjb]

The last proposed patches doesn't apply anymore and needs escaping on the attribute value.

[audrasjb]

Patch refresh and placeholder value escaping

[audrasjb]

In 47318.2.diff:

• Patch refreshed against trunk
• Placeholder atribute escaping with esc_attr

I also tested the alternative solution without placeholder but with a visible label and I'm afraid this is not very backward compatible. Maybe we could ship 47318.2.diff as an intermediate approach or a first compromise?

[azaozz]

Definitely in favor of using a native placeholder attribute, if that's possible.

But it would be great to use native placeholder.

Right, completely agree! :)

@afercia if I'm understanding it right, Firefox + NVDA works as expected, but Chrome + NVDA announces it twice. What are the chances this would be fixed upstream in Chrome or NVDA? My thinking is that the simpler the solution === the better and doing things in a standard way is most forward compatible.

I kind of like 47318.diff the most (with the escaping from 47318.2.diff), as it removes some old old JS as well.

[afercia]

Note: 47318.diff​ patches the built file src/wp-admin/js/post.js. It should patch src/js/_enqueues/admin/post.js instead.

[afercia]

doing things in a standard way is most forward compatible

@azaozz totally agree but we're not doing it anyways. The placeholder attribute should not be used as a label (#40331). It is meant to "associate additional information with an element, such as instructions or format requirements for an input field".

That said, not sure Chrome + NVDA are wrong. ​The accessible name and description are two different properties with different purposes. There's a complicated ​fallback mechanism for their calculation (see ​algorithm details). In our case:

• accessible name: the visually hidden <label>
• accessible description: the placeholder attribute

I'm not sure there's anything in the specs that states what should happen when the accessible name and description have the same value. The fact some browser / screen reader combinations announce only the label seems to me more an implementation choice of the browser / assistive technology to avoid redundancy. Note: I've updated the codepen.

That said, I'd recommend to not use the placeholder attribute this way.

If that's not possible, I'd tend to think it's better to accept the double announcement rather than making the input field not usable with some assistive technologies.

[audrasjb]

As per today's accessibility bug scrub, we should test 47318-alt.diff (specifically on IE11) as this is the easier way to fix the issue.

[afercia]

To further expand: the current markup in core is the best option for proper semantics and accessibility. The approach from 47318-alt.diff​ solves in a simple way the right-click problem. I tested also on IE 11 and all supported browsers.

I'd like to make a small improvement for no-JS support, as the Classic Editor provides the only fallback when JavaScript is disabled. When that's the case (not so uncommon for some companies and government bodies) the label position needs to be adjusted a bit. Will upload a new patch.

[afercia]

47318.3.diff​ elaborates on 47318-alt.diff​ and uses pointer-events: none;, which works in all supported browsers.

Additionally, when JavaScript support is off, it's not possible to just make the label text visible within the field. Otherwise, the entered/pasted title text will sit on top of the label text:

The patch adds some CSS for no-js, to move the label text above the input field.

Since I was there, I also added a label for the no-js textarea. This label is only visible when JavaScript support is off and hidden from all users when JavaScript support is on:

The label text "Content" should be generic enough also for Custom Post Types and I'd tend to think it doesn't need a filter. If this approach sounds good, any better wording is welcome:

Some testing would be nice :) With / without Classic Editor. With JavaScript support on and off.

[azaozz]

Replying to afercia:

...the current markup in core is the best option for proper semantics and accessibility.

Does that mean placeholder attributes are "semantically incorrect" feature that we should never use? :)

In any way, lest keep the current code if we cannot use a placeholder there. In that case 47318-alt.diff seems to fix this ticket.

I'd like to make a small improvement for no-JS support, as the Classic Editor provides the only fallback when JavaScript is disabled.

Thinking this should go in another ticket, pretty out of scope here.

However there is a subtle (or even not so subtle) difference between a web page and a web app "screen". As far as I understand the broad accessibility standards/best practices are targeted at web pages. Typically all users that visit a particular web page are considered "first time visitors", and the requirements seem adjusted for that.

An app however is pretty different. It is still accessed through the browser, but a "screen" in an app is not a web page. The users visit that screen time after time after time, so the design should account for that. Things that may be helpful for first time visitors of a web page quickly become pointless and annoying for a screen in a web app that is visited hundreds or thousands of times.

[azaozz]

In 46338:

Fix the context (right-click) menu when clicking the placeholder for the post title field on the classic Edit Post screen.

Props masummdar, audrasjb, afercia.
Fixes #47318.

[afercia]

Does that mean placeholder attributes are "semantically incorrect" feature that we should never use? :)

@azaozz that means placeholder should never be used as replacement for labels :)

They must only be used for a short hint for a sample value or a brief description of the expected format. Outside of that usage: yes, they're semantically incorrect.

• see the HTML spec (currently HTML 5.2): ​https://www.w3.org/TR/html52/sec-forms.html#the-placeholder-attribute (see also the big warning box there)
• see #40331
• see the WPCampus report on #47138: any improper use of the placeholder attribute will always be flagged as a compliance failure

[azaozz]

@afercia Yes, that's what I meant by pointing out the differences between a "web page" and a "web app".

Labels are good for forms on web pages where the visitor is considered to be unfamiliar with the page. However in apps, (visible) labels can easily become "out of place".

If you look at the HTML on that screen, yes, it is a form. But that screen is not a typical web form. It is much closer to a screen in Google Docs or in MS Word. The whole "meaning" of the screen is different there, the apps don't use labels the same way as web page forms :)

Both the HTML specs and the WPCampus report look at wp-admin as being a series of web pages. That's not the case, it is closer to being an application on Windows or Mac. The requirements there are not the same as for web pages.

That's why the accessibility team's work is so important and so hard :)

[afercia]

@azaozz I'm not sure the difference between web pages, apps, or single page apps matter in terms of accessibility :)

For many reasons, here's a few in random order:

• Getting familiar with a form or even a single input field varies with the users ability to "get familiar" :) there are cognitive impairments and diverse abilities to take into account.
• Until HTML will be used, it needs to communicate proper meaning whether it's a web app or traditional web form.
• This impact also a technical aspect related to how the elements accessible name is mapped to the accessibility tree and communicated via the operating systems accessibility APIs to assistive technologies, which not surprisingly varies across operating systems, browsers and assistive technologies.
• Encouraging the use of placeholder as replacement for labels opens a can of worm and will be abused: as in developers not providing a properly associated <label> element: not all screen readers read placeholder text aloud. Blind or visually impaired users may miss the hint completely if their software does not speak the placeholder content.
• Other assistive technologies, for example some speech recognition software, may not recognize the placeholder as the accessible name of an input field thus making users not able to easily use the input.
• Lack of a visible label will be flagged as a WCAG compliance failure anyways.
• Even not considering accessibility requirement, lack of visible labels is an usability concern. This is not new: many researches outlined this practice as harmful, most notably the research from the Nielsen Norman Group (2014): ​https://www.nngroup.com/articles/form-design-placeholders/
• Placeholders disappear as soon as you type a value :)

Regarding the last point, of course it has a greater impact on forms with multiple fields. I'd agree it has a minor impact for an UI with a single form field. However the previous considerations about cognitive impairments and support still apply.

In forms with multiple input fields, once you enter a value, you're left without any clue of what an input is about. See screenshot below. Also consider validation, error reporting, and suggestions for correction (all WCAG requirements): how they could be ever properly handled without visible labels? :)

[afercia]

Form with multiple input fields an no visible labels: which is which?

[afercia]

Quoting 2 more points from #47138 :)

• when an input field with no visible label is filled with a value, speech recognition users cannot see the name they can speak to set focus on the field
• low-vision users with increased text-size (via operating system settings or only-text zoom) may not be able to see the whole placeholder even when it's visible, if its value is clipped by the edge of the input

[afercia]

Both the HTML specs and the WPCampus report look at wp-admin as being a series of web pages. That's not the case, it is closer to being an application on Windows or Mac. The requirements there are not the same as for web pages.

You're right. Technically, the requirements for an authoring tool are not the same as the ones for Web Content (the W and C in WCAG). Actually, they're the ATAG (Authoring Tool Accessibility Guidelines) which are stricter than WCAG :)

Note: for the sake of simplicity, you may want to think at ATAG as a superset of the WCAG plus an additional set of rules specific to authoring tools and content production.

[azaozz]

Replying to afercia:

Hmm, I think there is a slight misunderstanding here :)

Technically, the requirements for an authoring tool are not the same as the ones for Web Content (the W and C in WCAG). Actually, they're the ATAG (Authoring Tool Accessibility Guidelines) which are stricter than WCAG :)

Right, exactly. We shouldn't be looking at that as a "text input field in a web form". It is an "application element" and as such it should comply with something like ATAG (which is still only targeted at web based applications, not for all computer applications) rather than with WCAG (which is for web pages). I understand that in the background it uses HTML, CSS and JS, but that's just the "technology layer". It shouldn't make any differences what technology is used, the "app element" will have to be accessible regardless of it.

Encouraging the use of placeholder as replacement for labels...

Think there is the misunderstanding. I personally quite dislike placeholders as implemented in HTML forms text elements. And I think many people share that, not surprisingly placeholders are not that common on the web. Having said that, we shouldn't be limiting what technical solutions we use in order to make an application element more accessible. If it must be a placeholder, it will be :)

Form with multiple input fields an no visible labels: which is which?

This is a nice example but it doesn't apply here :) There is only one text input field on that screen and the content of that field is not cryptic. It was typed by the user.

The tl;dr: Screens in wp-admin are not web page forms. They are "application screens". As such they should follow general computer applications accessibility standards and guidelines, not exactly WCAG which mostly applies to web pages.

[afercia]

The tl;dr: Screens in wp-admin are not web page forms. They are "application screens". As such they should follow general computer applications accessibility standards and guidelines ...

We agree we disagree :) To me, WordPress is a form-based application which uses HTML, which is rendered in a browser, thus all the base Web technologies and standards apply.

I'm not sure I understand how defining WP an "application" makes any difference for the users in the practical everyday usage. There are tons of usability studies, years of user testing and research related to accessibility, specifications, etc., and these general principles don't change depending if we call a software "web page forms based" or anything else.

From an usability and accessibility perspective, I listed a few, argumented, reasons why a placeholder used improperly is harmful. These come from years of user testing and research. That doesn't change whether we call WordPress an "application" or a "web form thing".

Technically, whether a software is web forms based or it's something more similar to a desktop application, the way operating systems expose information to devices and assistive technologies is the same. Any "client", whether it's a browser or other software, communicates to the operating system via ​the Accessibility APIs. The OS then exposes the information to devices and assistive technologies. Anything that runs in a browser needs to use proper HTML to make the info passed to the Accessibility APIs correct.

By not applying standards in our development, and by using an HTML element / attribute against the specification, we actually sabotage the Accessibility APIs thus preventing other software to work correctly and by that excluding the persons who use that software.

Different persons have different needs. In our life, our own needs change over time. Standards and accessibility guidelines are the only way to build software that aims to be inclusive and usable by everyone. It's not just because of a rigid, strict, approach to standards. It's because devices and assistive technologies are designed based on those standards. When a user interface is designed and built against the standards, devices and assistive technologies may not work as expected or not work at all. And if they don't work, the users won't be able to use the software. They would be excluded. Personally, I'd rather go for inclusion :)

Not to mention WordPress is the only publishing platform around to have an administration interface that is easy to use and partially accessible. It is the only chance for many users with diverse abilities to be empowered to publish content. To me this 100% matches the WordPress principle to democratize publishing, also regardless of the ability level.

not exactly WCAG which mostly applies to web pages

Right again :) As I mentioned previously, the more appropriate standard for authoring tools and "applications" that produce web content is ​ATAG. It's more strict than WCAG. Glad to switch to ATAG starting tomorrow if you feel that's the more appropriate standard :)

And by the way, the correct usage of the placeholder attribute is not WCAG or ATAG: ​it's HTML in the first place ;)

[afercia]

we shouldn't be limiting what technical solutions we use in order to make an application element more accessible. If it must be a placeholder, it will be :)

Hm, actually a placeholder with no visible label makes an element less accessible. I'm not sure I understand your point.

[azaozz]

Replying to afercia:

We agree we disagree :) To me, WordPress is a form-based application which uses HTML, which is rendered in a browser, thus all the base Web technologies and standards apply.

Yeah, seems we are still not exactly on the same page here :)

The difference (pretty big difference actually) is how the application is used, not the underlying technology.

Would you say the same for Gmail? A better example: would you say the same for Slack? :)

What if you open Slack in the browser and then open the Slack desktop app next to it? Any differences? So why should it look and behave differently just because it runs in a web browser?

[afercia]

The difference (pretty big difference actually) is how the application is used, not the underlying technology.

I totally agree :) The most important thing is how users use the application and their needs, considering users of all abilities. I'm not sure I understand what you're actually suggesting. Should WordPress not follow the only existing specifications (whether it's WCAG or ATAG) to include people of all abilities? How this would relate to the principle of an inclusive community that builds an inclusive software to democratize publishing?

To me, at the end any technical detail doesn't really matter. Any software should be built do be usable by everyone.

The web standards movement started about 25 years ago. WCAG are 20 years old. If you're suggesting we should ignore all this and go back to an inextricable HTML soup with no semantics and no standards at all, please just let me know :)

Would you say the same for Gmail? A better example: would you say the same for Slack? :)

Those are pretty different software and by the way they use a lot of ARIA and scripting to rebuild the semantics and native interaction they destroy by not using standards. Just look at the tons of role and aria-* attributes they use, not to mention all the scripting part.

why should it look and behave differently just because it runs in a web browser?

Because of HTML :) HTML is literally the language (as in spoken language) we use to convey meaning to software and, through software, to users who use that software.

In a previous comment I posted a link to an introductory article on what the ​Accessibility API are. Maybe worth getting familiar with that to have a better understanding of how the whole thing works and what would happen when not following standards.