The search field for module names is a great addition to the Module Install /Uninstall.
This is a primary navigation tool at the page, and point where newcomers are lost.

But current implementation is not usable because:

1) it's really hard to point (make active) and basically find the input
2) the description under field and placeholder are too faded
3) additionally would be great to make filter "sticky"

Current state

Files: 

Comments

Greg Sims created an issue. See original summary.

cilefen’s picture

Component: install system » extension system
Issue tags: +JavaScript
Wim Leers’s picture

I would *love* this. It used to work this way. But apparently it is bad for accessibility. At the cost of great usability for sighted users, sadly.

It's an unfortunate compromise. Maybe something has changed in the meantime though.

vprocessor’s picture

Hi guys!

Please, can you explain details for this task, not sure that I understand what did you mean
Maybe you mean default focus at search field on modules page?

Thanks

Greg Sims’s picture

@vprocessor I'm not sure of the correct terminology. The goal is this: When a user loads the Module Install page, he should be able to type the name of the module that they want to install without clicking the cursor into the search box first. This is also true for the Module Uninstall page. I think this is likely,

default focus at search field on modules pages

.

When I am debugging a module, I need to Install/Uninstall the module a couple of times before I understand the issue and fix it. This change will speed up this process. All of our custom modules begin with the characters 'rsm_' so they are very easy to find with the search box.

cilefen’s picture

@Greg Sims The issue summary is short but it is pretty clear to me. You could maybe clear it up for others by incorporating your prior comment.

vprocessor’s picture

vprocessor’s picture

Status: Active » Needs review
andypost’s picture

Status: Needs review » Reviewed & tested by the community

tested manually, it works!
really useful!

Wim Leers’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Usability, +accessibility, +needs accessibility review, +Needs usability review

See #3.

nod_’s picture

I don't think all our users with visual difficulties are all cured yet. Won't fix.

nod_’s picture

@Greg Sims: think of it as a show of support for them. And to start with: there is module filter in core and Ctrl+F is actually useful now. Surely a click is not that bad. Contrib can always reduce a11y with a form_alter of some kind :)

andypost’s picture

Yep, let's get more reviews!
My POV that this page is 99% of time will be visited by developers/builders to enable module.
So having "autofocus" of that will save a lot of hours removing this "single click"

I call to reconsider that so linking previous attempts

vprocessor’s picture

Agree with @Andypost, I think it is useful to have autofocus without any additional keyboard manipulations

andypost’s picture

This is a modules page, so the primary action is to find module and enable, so the argument in #2096347-19: Add "autofocus" attribute to the module search is totally wrong
Maybe autofocus does not fits for a11n but for this page the primary interaction is search
So maybe patch should detect screenreaders (maybe modernizr) and set focus for all others that are 99%

cweagans’s picture

Version: 8.0.0 » 8.0.x-dev
Priority: Normal » Minor
Status: Needs review » Closed (won't fix)

Accessibility is a gate and it's not really up for debate. If you have a solution that makes this usable for screen reader users (and you have verified that by testing it yourself or asking a screen reader user for assistance), feel free to reopen. Otherwise, this has already been debated, redebated, and argued in pretty much every way in many other issues. This is still a won't fix.

Write a contrib module if it bothers you that much, or just use Drush.

@andypost, saying that an argument from somebody that this actually affects is insensitive. I encourage you to try the module page with autofocus enabled via screen reader software. Using the modern web is really damn hard if you can't see what's happening. Drupal shouldn't contribute to that.

Adjusting issue metadata for accuracy.

andypost’s picture

Title: Set Cursor in the Search Field for Module Install/Uninstall » Make Search Field for Module Install/Uninstall usable
Version: 8.0.x-dev » 8.1.x-dev
Category: Feature request » Bug report
Priority: Minor » Normal
Issue summary: View changes
Status: Closed (won't fix) » Postponed
Issue tags: -accessibility, -needs accessibility review +D8UX usability, +Usabilty
FileSize
58.04 KB
51.76 KB

Ok, let's postpone then and re-scope to theme change and improve usability of primary interaction

cweagans’s picture

No matter what solution we come up with here, anything that automatically focuses a field on the page needs accessibility review.

This is also going to need an issue summary update on why the current field is not "usable".

andypost’s picture

there's nothing to review yet, summary already updated in #17

droplet’s picture

Make it Configurable.

Accessibility killing Drupal silently. This issue is not alone:
#2346973: Replace jQuery UI autocomplete with Select2

Greg Sims’s picture

Good idea @droplet! How about a radio button in User Profile for "Using Screen Reader -- Yes/No". The default would be Yes for reasons mentioned above.

With this much energy surrounding this issue -- there must be a solution that will work for the entire community.

Greg Sims’s picture

Status: Postponed » Needs work

Hopefully we can return to "Needs Work".

andypost’s picture

Status: Needs work » Postponed

there's no patch, so status wrong. also 8.1 still not open

Greg Sims’s picture

Views has a similar search filter. Perhaps all of these search boxes should incorporate "autofocus'.

mgifford’s picture

Status: Postponed » Needs work

So hopefully in early January https://www.drupal.org/node/2455081

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mgifford’s picture

Issue tags: +keyboard focus

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.