Make WordPress Core

Opened 13 years ago

Closed 10 months ago

Last modified 10 months ago

#15631 closed enhancement (fixed)

Custom fields auto-focus

Reported by: jane's profile jane Owned by: joedolson's profile joedolson
Milestone: 6.3 Priority: normal
Severity: normal Version: 3.1
Component: Editor Keywords: has-patch has-ux-feedback has-testing-info commit has-screenshots
Focuses: ui, accessibility Cc:

Description

When you are on the post editor (page editor, whatever), if you want to create a new custom field and click on Create New, it should auto-focus on the text input field that appears.

Attachments (7)

15631.diff (1.1 KB) - added by batmoo 13 years ago.
15631-datalist.diff (1.9 KB) - added by sabernhardt 22 months ago.
datalist concept
15631.2.diff (2.5 KB) - added by sabernhardt 22 months ago.
updating focus and labels in current interface
15631.3.diff (2.5 KB) - added by joedolson 11 months ago.
Refreshed patch
15631.4.diff (3.2 KB) - added by joedolson 11 months ago.
Use button appearance & move add custom field out of table
custom-fields.png (37.0 KB) - added by oglekler 10 months ago.
2023-06-22_22-41-27.png (19.4 KB) - added by oglekler 10 months ago.

Download all attachments as: .zip

Change History (40)

@batmoo
13 years ago

#1 @batmoo
13 years ago

  • Cc batmoo@… added
  • Keywords has-patch added

Moved inline javascript to post.dev.js and set the field to auto-focus.

Should the input be reverted back to the select once a new custom field is added? It just seems weird (possibly confusing) because of the "cancel" link.

#2 @sabreuse
11 years ago

  • Component changed from UI to Editor
  • Keywords ui-focus added

#3 @chriscct7
9 years ago

  • Keywords needs-refresh ux-feedback added

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 years ago

#5 @karmatosed
7 years ago

  • Keywords has-ux-feedback added; ux-feedback removed

I agree that the input should revert once custom field is added, without cancel link. If this is still an issue it will need a patch check due to age.

I am tackling this during weekly ux-feedback triage.

#6 @sabernhardt
3 years ago

  • Focuses accessibility added

Changing the focus behavior might help, yet I'm more concerned about the lack of a label on the meta key input field. So even if you think to use Shift + Tab to go back to the meta key input, a screen reader cannot say what you are editing.

Last edited 3 years ago by sabernhardt (previous) (diff)

#7 @franrosa
23 months ago

Maybe I am missing something here, but would not adding a text input on the list of options to either search existing fields or writing the name of a new one to add eliminate the need to have that dual UI with that confusing New/Cancel pattern?

It would be similar to the existing UI for links, with the added option to 'Create new' when no result is found. (Quick mockup for clarity: https://drive.google.com/file/d/1VvPlU_j5aXDTN445CkeMmGNpBk2dVko8/view?usp=sharing)

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


22 months ago

@sabernhardt
22 months ago

datalist concept

@sabernhardt
22 months ago

updating focus and labels in current interface

#9 @sabernhardt
22 months ago

  • Keywords needs-refresh removed

This is a feature of the classic editor that the block editor adopted. There was some trouble creating a custom fields UI element there in the months before WordPress 5.0, which could be easier now. Discussion about an element like the block editor's link autocomplete would fit better in the Gutenberg repo.

Yet your suggestion led me to think about the native datalist element. Firefox still has a bug with the dropdown, but the element could be worth considering.

15631-datalist.diff

  • Replaces select with a datalist of the same options
  • Uses the "Name" table header as the label for the input field
  • Removes the "Enter New"/"Cancel" toggle link
  • Would need CSS editing for the dropdown triangle position

I also created 15631.2.diff to follow prior feedback:

  • Ensures that the "Name" table header as the label for the select element
  • Creates a "New custom field name" ARIA label for the input field
  • Converts the toggle link to a button
  • Moves focus to the input after clicking "Enter New", and to the select after "Cancel" or "Add Custom Field"
  • Keeps the JS inline (I would have added it to post.js, but the block editor apparently does not load it)
Last edited 17 months ago by sabernhardt (previous) (diff)

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


16 months ago

#11 @joedolson
13 months ago

  • Milestone changed from Future Release to 6.3
  • Owner set to joedolson
  • Status changed from new to accepted

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


13 months ago

#13 @ryokuhi
13 months ago

  • Keywords needs-testing added

We reviewed this ticket today during the Accessibility Team's bug scrub.
The ticket needs testing to check if patch 15631.2.diff still applies clearly or if a refresh is needed.

#14 @annashopina
12 months ago

  • Resolution set to invalid
  • Status changed from accepted to closed

Test Report
This report validates that the issue is still reproduced.
Patch tested: https://core.trac.wordpress.org/ticket/15631
Environment
OS: macOS 13.1
Web Server: Nginx
PHP: 8.0
WordPress: 6.3
Browser: Chrome 111.0.5563.146
Active Plugins:
Classic Editor
Actual Results
The issue was not resolved with a patch.
Additional Notes
Steps to reproduce:
Install and activate Classic Editor
Open any post/page
Open 'Screen options
Enable 'Custom fields'
Add custom field
Observe where is the focus
Add Inline:
Actual result: It's not auto-focused on the text input field that appears.

Expected result: It should auto-focus on the text input field that appears.

#15 @annashopina
12 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#16 @joedolson
11 months ago

Note: the test by @annashopina looks like it was testing whether focus was moved when using the 'Add Custom Field' button, but this ticket is about moving focus to the text field when 'Enter New' is chosen to define a new custom field name. So that test isn't valid.

I just tested, and the patch tests fine. I'm uploading two patches; 15631.3.diff is a refresh of the previous patch, 15631.4.diff changes the 'Enter new' button to use the button-small appearance (matching the delete/update buttons on existing fields & avoiding the semantic confusion of something that is a button but looks like a link) and moves the 'Add Custom Field' button out of the table, because the semantics don't make sense.

@joedolson
11 months ago

Refreshed patch

@joedolson
11 months ago

Use button appearance & move add custom field out of table

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


11 months ago

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


10 months ago

#19 @oglekler
10 months ago

  • Keywords has-testing-info has-screenshots added

Hi @joedolson, can you please check the patch, somehow it is not applicable.

I added a screenshot to get more clarity on what custom fields are.

Info to test:

  • Activate Classic editor (if applicable)
  • Open a page to edit
  • Open Screen options (right top corner of the window) and add a checkmark to Custom fields
  • Scroll the page down and start to add Custom fields
  • Deactivate Classic editor (if applicable)
  • Open a page to edit
  • Open settings (three vertical dots in the right top corner)
  • Choose Preferences, open the Panel tab and switch Custom fields to on
  • Click Enable & Reload
  • Scroll page down and start to add Custom fields

#20 @joedolson
10 months ago

@oglekler I'm not able to reproduce any problems with applying the patch; can you provide any additional detail?

#21 @joedolson
10 months ago

Moving focus to the select input after adding a custom field fails the first time a custom field is added, because the select does not yet exist.

This also causes a weird visual where the new custom field input disappears when you add the first custom field.

I think that changing the visibility of the custom field interface doesn't make sense when adding custom fields; it's a better user experience in my opinion if adding a custom field doesn't otherwise update the UI - just adds the new field.

#22 @oglekler
10 months ago

@joedolson I cannot apply patch to trunk even if files are in place and there shouldn't be any conflicts within the code 🤷

$ git apply 15631.4.diff
error: wp-admin/css/edit.css: No such file or directory
error: wp-admin/includes/template.php: No such file or directory
$ git apply --directory=src/ 15631.4.diff
error: patch failed: src/wp-admin/css/edit.css:1068
error: src/wp-admin/css/edit.css: patch does not apply
error: patch failed: src/wp-admin/includes/template.php:724
error: src/wp-admin/includes/template.php: patch does not apply
Last edited 10 months ago by oglekler (previous) (diff)

#23 @joedolson
10 months ago

I haven't tried the patch on git; I've only been working in SVN. Seems unlikely that would be the issue, but it's possible. I can convert this to a PR and see if you can apply it then.

This ticket was mentioned in PR #4635 on WordPress/wordpress-develop by @joedolson.


10 months ago
#24

Not a final patch; shifting to PR for testing.

Removes focus change & input change on adding custom field; changes context of wp lists .add method.

Trac ticket: https://core.trac.wordpress.org/ticket/15631

#25 @joedolson
10 months ago

PR removes focus change after adding a custom field and moves the nonce inside the table, where wpList.nonce() expects to find it.

#26 @oglekler
10 months ago

@joedolson thank you, I was able to install the patch. Cursor is inside as required after pressing button "Enter new", I was able to add data, to use tab to navigate and update meta. Screenshot is above.

Software: WP (6.3-alpha-55505-src), Google Chrome 114.0.5735.134 (desktop).

#27 @joedolson
10 months ago

  • Keywords commit added; needs-testing has-screenshots removed

Thanks, @oglekler

#28 @joedolson
10 months ago

  • Keywords has-screenshots added

#29 @sabernhardt
10 months ago

If anyone wonders about keeping the #postcustomstuff #newmetaleft a selector when the link was replaced, some plugins add their own a element in a newmetaleft container (including WooCommerce).

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


10 months ago

#31 @joedolson
10 months ago

I've explored a few of the plugins listed, and haven't found anything to actually test. Simple Job Board doesn't use a link; they use a div, and operate it using their own custom JS. Backup & Restore WordPress only has that reference in something that looks like a local vendor reference, not an actual used file. WooCommerce has the reference, but it doesn't seem like it's actually being used? At least, in testing, custom fields on orders used the core implementation. So, I don't know how much of a concern this really is...I think this should just move forward as is. If there are problems, we'll find out.

#32 @joedolson
10 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 56018:

Editor: Improve accessibility of new custom field UI.

Add labels; change Enter new/Cancel link to a button; move focus to input when creating new field; move Add Custom Field out of fields table.

Props jane, batmoo, karmatosed, franrosa, sabernhardt, annashopina, oglekler, joedolson.
Fixes #15631.

@joedolson commented on PR #4635:


10 months ago
#33

Closed in r56018

Note: See TracTickets for help on using tickets.