Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#50846 closed defect (bug) (fixed)

Customize: Add Widget on Mobile does not Auto-Focus Widget Search

Reported by: jeryj's profile jeryj Owned by:
Milestone: 5.8 Priority: normal
Severity: normal Version:
Component: Customize Keywords:
Focuses: ui, accessibility, javascript Cc:

Description

On mobile devices, the search input does not receive focus after clicking the Add a Widget button.

To reproduce, on a mobile device or emulator (this is device dependent, not screen size, so you can't just reduce your desktop browser width):

  • Go to the Customizer
  • Select "Widgets"
  • Select the "Add a Widget" button
  • Widget Search will open, but focus is not placed within the search. Focus remains on the Add a Widget button, so screen readers don't have immediate access to the new overlay

I believe the fix, if this method is approved, would be to remove the mobile check before focusing from wp-admin/js/customize-controls.js on [line 367 - 369](https://github.com/WordPress/WordPress/blob/3dd9628aae507ee027757b7c9c17506d4ff45ef8/wp-admin/js/customize-widgets.js#L367-L369) that was added by https://core.trac.wordpress.org/changeset/32243.

Apologies for the Github link, I couldn't track down the customize-controls.js file in trac.

Change History (14)

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


4 years ago

#2 follow-up: @afercia
4 years ago

Teh check for mobile was introduced in https://core.trac.wordpress.org/changeset/32243

Some investigation on the reason why it was introduced would be nice before removing it :)

#3 @afercia
4 years ago

  • Milestone changed from Awaiting Review to 5.6

#4 in reply to: ↑ 2 @afercia
4 years ago

Replying to afercia:

Some investigation on the reason why it was introduced would be nice before removing it :)

First thing to check: on mobile, setting focus on the input field would make the on-screen keyboard appear, which I guess is what the original commit wanted to avoid.

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


4 years ago

#6 @afercia
4 years ago

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

This ticket was discussed during today's accessibility bug-scrub: Noting that in WordPress 5.6 the Widgets UI in the Customizer may change considerably. Let's keep this ticket open in the meantime and see what happens.

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


3 years ago

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


3 years ago

#9 @audrasjb
3 years ago

Worth noting the UI is not going to change in the customizer in WP 5.6, so the ticket is still relevant for this release :)

#10 @afercia
3 years ago

  • Milestone changed from 5.6 to Future Release
  • Owner afercia deleted
  • Version 5.5 deleted

WordPress 5.6 is in Beta 1 phase now and there's no identified solution for this issue yet. Punting to Future Release.

As mentioned in a previous comment, the current behavior appears intentional to prevent mobile device on-screen keyboards to open when the search field receives focus.

However, this isn't ideal for mobile screen reader users as there's basically a focus loss.

Worth also mentioning that the way focus is managed (or not) depending on whether the device is "mobile" appears inconsistent across the Customizer. For example, in the Menus section > Add menu item does set focus also on mobile. Therefore there a decision should be made first on what the ideal behavior is and then the behavior should be implemented consistently across the Customizer interface.

#11 @celloexpressions
3 years ago

  • Keywords needs-testing added
  • Milestone changed from Future Release to 5.8

Now that the widget inserter is the block inserter in 5.8, is this issue fixed? Or, is focus set to the intended element when inserting a block-widget?

Or, do we want to keep this ticket open to explore auto-focus patterns for other inserter UIs?

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


3 years ago

#13 @joedolson
3 years ago

  • Keywords needs-testing removed
  • Resolution set to fixed
  • Status changed from assigned to closed

When adding a new block widget in the customizer, focus does move to the search field as expected, so I'd consider this to be resolved.

I'm not sure I see an advantage to keeping this ticket open to explore auto-focus generally. It's not a widely used interaction, and I know that there have been other tickets addressing it previously.

Closing ticket as fixed; this can be re-opened for further discussion if anybody else disagrees!

Note: See TracTickets for help on using tickets.