WordPress.org

Make WordPress Core

Opened 4 weeks ago

Last modified 6 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 needs-testing 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 (4)

context-menu-wrong.png (17.6 KB) - added by azaozz 4 weeks ago.
context-menu-correct.png (22.0 KB) - added by azaozz 4 weeks ago.
47318.diff (1.9 KB) - added by masummdar 4 weeks ago.
A possible fix to #47318
47318-alt.diff (281 bytes) - added by masummdar 4 weeks ago.
This could be a fix for the right click without touching current code for floating label.

Download all attachments as: .zip

Change History (13)

#1 @azaozz
4 weeks 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
4 weeks ago

A possible fix to #47318

#2 @masummdar
4 weeks 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
4 weeks 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
4 weeks ago

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

#4 @masummdar
4 weeks 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.


4 weeks ago

#6 @azaozz
4 weeks 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
4 weeks 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.


2 weeks ago

#9 @noisysocks
6 days ago

  • Owner set to azaozz
  • Status changed from new to assigned
Note: See TracTickets for help on using tickets.