WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 4 days ago

#47318 assigned defect (bug)

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

Reported by: azaozz Owned by: azaozz
Milestone: 5.3 Priority: normal
Severity: minor Version:
Component: Administration Keywords: good-first-bug has-patch has-screenshots
Focuses: accessibility Cc:

Description

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.

Attachments (5)

context-menu-wrong.png (17.6 KB) - added by azaozz 3 months ago.
context-menu-correct.png (22.0 KB) - added by azaozz 3 months ago.
47318.diff (1.9 KB) - added by masummdar 3 months ago.
A possible fix to #47318
47318-alt.diff (281 bytes) - added by masummdar 3 months ago.
This could be a fix for the right click without touching current code for floating label.
47318.2.diff (850 bytes) - added by audrasjb 4 days ago.
Patch refresh and placeholder value escaping

Download all attachments as: .zip

Change History (18)

#1 @azaozz
3 months ago

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
3 months ago

A possible fix to #47318

#2 @masummdar
3 months ago

  • Keywords has-patch needs-testing added

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.

#3 @afercia
3 months ago

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
3 months ago

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

#4 @masummdar
3 months ago

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 .

This ticket was mentioned in Slack in #core by sergey. View the logs.


3 months ago

#6 @azaozz
3 months ago

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.

#7 @afercia
3 months ago

  • Keywords has-screenshots added

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

http://cldup.com/pfa3I2pY8H.png

Chrome + NVDA

http://cldup.com/szHvHsX9pS.png

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

http://cldup.com/Cgqcvjkq_Q.png

This ticket was mentioned in Slack in #core by marybaum. View the logs.


3 months ago

#9 @noisysocks
2 months ago

  • Owner set to azaozz
  • Status changed from new to assigned

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


4 days ago

#11 @audrasjb
4 days ago

  • Keywords needs-refresh added

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

@audrasjb
4 days ago

Patch refresh and placeholder value escaping

#12 @audrasjb
4 days ago

  • Keywords needs-testing needs-refresh removed

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?

#13 @azaozz
4 days ago

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.

Note: See TracTickets for help on using tickets.