WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#29102 closed enhancement (wontfix)

Plugin Installer: Autofocus search field

Reported by: paulwilde Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.0
Component: Plugins Keywords: has-patch 2nd-opinion needs-refresh
Focuses: ui, accessibility, administration Cc:
PR Number:

Description (last modified by ocean90)

Prior to 4.0 the search field had an autofocus (see [21143]), but with the new filter bar the search field is no longer auto-focused.

Attachments (1)

added_autofocus_to_input_attrs__This_will_regain_the_autofocus_capability_and_this_does_no.patch (685 bytes) - added by phpmypython 5 years ago.
Added in auto focus to the plugin search field through the input_attrs variable

Download all attachments as: .zip

Change History (19)

#1 @ocean90
5 years ago

  • Description modified (diff)
  • Type changed from defect (bug) to enhancement

Should be disabled for mobile devices.

@phpmypython
5 years ago

Added in auto focus to the plugin search field through the input_attrs variable

#2 @phpmypython
5 years ago

  • Focuses ui accessibility administration added
  • Keywords has-patch added
  • Resolution set to invalid
  • Status changed from new to closed

My First patch. seemed rather ease and there we go.

#3 follow-up: @ocean90
5 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#4 in reply to: ↑ 3 @phpmypython
5 years ago

Replying to ocean90:
Hello, does your last comment indicate that my resolution was not suitable?

#5 follow-up: @TobiasBg
5 years ago

No, no worries :-) ocean90 just reopened the ticket so that it can be worked on. Only after one of the WordPress core developers actually takes your code (after they check that it does what it's supposed to do) and applies it to the WordPress code, will the ticket be marked as "closed".

#6 in reply to: ↑ 5 @phpmypython
5 years ago

Replying to TobiasBg:

No, no worries :-) ocean90 just reopened the ticket so that it can be worked on. Only after one of the WordPress core developers actually takes your code (after they check that it does what it's supposed to do) and applies it to the WordPress code, will the ticket be marked as "closed".

Thanks for filling me in, this is my first patch so im still getting used to the core trac system.

#7 @helen
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

I am disinclined to make this change, and consciously made the decision not to include it when changing the install plugins screen. It made some amount of sense to autofocus when it was essentially the only thing on the screen, but makes less sense now that the initial screen isn't just a text input and a tag cloud. Also mobile considerations. Closing.

#8 @ocean90
5 years ago

#29541 was marked as a duplicate.

#9 @McGuive7
5 years ago

  • Keywords 2nd-opinion added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

I disagree. I hear what you have to say Helen, but to my way of thinking there is no obvious disadvantage to autofocusing other then a re-ordering of priority tab indexes. On the plus side, this would save one click every time someone searches for a plugin, which equals literally millions of clicks. Is there a downside that outweighs this convenience?

#10 @McGuive7
5 years ago

PS - not sure if I'm supposed to switch a ticket back to "open" when adding another request/opinion. Apologies if I wasn't supposed to!

#11 @SergeyBiryukov
5 years ago

  • Milestone set to Awaiting Review

#12 @Denis-de-Bernardy
5 years ago

Auto-focus only really makes sense when it's the only natural thing you're supposed to be doing. And then only on a page that is short enough that you wouldn't want to hit the space bar in order to scroll. Anything else and you end up irritated (admittedly power-) users who mindlessly hit space and begin to curse at the clunky UI that is imposed upon them.

Imho, the plugin installer screen doesn't qualify for either of these two criteria.

Plus, it would be inconsistent with the other WP admin screens, where auto-focusing doesn't occur.

Suggesting close as wontfix.

Last edited 5 years ago by Denis-de-Bernardy (previous) (diff)

#13 @Denis-de-Bernardy
5 years ago

That said, what *would* make sense imho would be to ensure that hitting the tab key (a single time, rather than several times) leads you straight to the search field on any admin screen that supplies one.

#14 @jodzeee
5 years ago

I agree with McGuive7. If I click Plugins > Add New, what would I likely do next? Type the name or keyword for the plugin I'm looking for in the search box. NOT choose one of the "featured" plugins that's presented to me first. What else would be the natural thing you're supposed to be doing there?

Also, when working on a large screen, I always struggle to even find the search field since it's so far to the right. I was going to suggest moving it, but I realize that upper right is standard for UI. Having the field in focus would eliminate the need for me to find it as well as moving my mouse all the way over there to click, then type.

Last edited 5 years ago by jodzeee (previous) (diff)

#15 @McGuive7
4 years ago

  • Keywords needs-refresh added

Any update on this one? It seemed to be nay-sayed, but per the 80% WordPress guideline ("The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use") this seems like a natural fit. I'm imagining that 80+% of most users want to type a plugin name in the search box after clicking to add a new plugin, and many folks I've asked have confirmed this is their natural flow. Certainly some percentage of users navigate to one of the other tabs available via that screen, however I have to imagine (and would love to know if someone has actual data on this) that the search box is far and away the most used method of finding plugins. So I'm all for it.

One consideration that I'd love anyone who's involved with #accessibility to weigh in on - are there any negative implications for those using screen readers if autofocus is used?

#16 @rianrietveld
4 years ago

Discussed this with @afercia and we agree with @helen this ticket should be closed.
So from an accessibility point of view: autofocus interferes with the normal tab order, forcing another tab order for screen reader and keyboard only users.

Autofocus makes sense just in very limited cases, for example a page with just a form, where the only task to accomplish is filling in the form, otherwise you're just changing the context without informing users, that would be potentially confusing not only for screen reader users but also for people with low vision, cognitive disabilities etc.

Last edited 4 years ago by afercia (previous) (diff)

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


4 years ago

#18 @rianrietveld
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.