Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.When I visit
my_drupal_domain/admin/modules
the cursor is placed in the "Enter module name…" search field. This field should allow to filter shown modules by their name, but focus shouldn't be placed into it when loading the page.
This happens using Windows and Mac OS X and it is really annoying for blind users.
I don't know the reason why, but this happens only when overlay module is disabled.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | module-filter-remove-autofocus-1932958-1.patch | 521 bytes | andrewmacpherson |
Comments
Comment #1
andrewmacpherson commentedConfirmed this behaviour, with Chromium 24.
It's a bit annoying for sighted keyboard-only users too. I don't think /admin/modules is a good scenario for autofocus, as there are a number of useful links preceding the module filter text field.
The overlay uses an iframe, and I suspect that's why the autofocus doesn't happen when the overlay is present. (Focussing elements inside iframes is difficult for some reason I don't fully understand).
This minor patch removes the autofocus behaviour from Drupal.behaviors.tableFilterByText
Comment #2
mgiffordOn FF & http://simplytest.me can I confirm that this patch changes the focus.
@falcon - would be good if you had a chance to review with a screenreader but I think this is RTBC.
Comment #3
falcon03 commented@andrewmacpherson: thank you very much for the patch. It works great for me too!
@mgifford: Sure, this is RTBC. I just hadn't had time to test the patch before.
I tested it with Mac OS X using Voiceover in Safari and Chrome.
BTW, I have a question: do we need feedback from the usability team?
Comment #4
Bojhan commentedThis sounds fine, we added it because we where under the impression it would not have any negative a11y impact. We can commit this, though it would be lovely to know more on the why, because its not clear to where we can and cant use autofocus when it comes to a11y.
Comment #5
falcon03 commented@bojhan: as a general rule, we should avoid using autofocus unless the user is expecting this behaviour and can safely not care about the content of the page that is displayed before the "autofocused" element because he/she has already read it. E.G. A good use-case for autofocus is the Views UI. When clicking on a link in the Views UI and a modal dialog appears, focus can (and should) be moved into the dialog because the user is expecting this behaviour and it makes no sense for him/her to read again the content of the page.
IMO, though, the decision of using/not using autofocus should be made on a case-by-case basis. If autofocus is not used properly it can be very disorienting.
Comment #6
andrewmacpherson commentedThe way I understand it, autofocus is only reasonable when there is a clear expectation that everybody visiting the page will need to use it.
Autofocus on the module filter is disorientating because it bypasses the other major task (uninstall).
The module filter field assists with exploring the list, but it's only useful if you already have a rough idea of what you are looking for. It's quite reasonable to browse the module list without using the filter.
Comment #7
mgiffordSo would autofocus be useful for:
/search/node
/node/add/article
Where are other places where there is a single purpose?
Module selection isn't because there are a few ways folks might want to navigate through that content.
Comment #8
wim leersI understand why this is necessary, but it seriously hinders my productivity. The >95% use case for the modules page is to search for modules, either to enable or disable them.
Comment #9
falcon03 commented@mgifford: well, as I already said I prefer avoiding autofocus when possible. It would make sense to add it to the content search field, but I am not sure how blind users would react.
So, before adding autofocus the way you suggested I would like to perform some usability testing with blind users! This seems something to investigate further for D9! ;)
Comment #10
dries commentedCommitted to 8.x. Thanks.
Comment #11
sunHm. Auto-focusing the search field was really helpful. I agree that there is a very high chance for visitors of the page to want to use it.
Comment #13
yannickooI just opened another issue #2096347: Add "autofocus" attribute to the module search
Comment #13.0
yannickooadding something
Comment #14
jessebeach commentedfalcon03, is there some way we could use
aria-describedbyto give non-visual users more information about the input field having autofocus? The interaction of focusing the search field is really nice. It's the primary use case on the page.Comment #15
mgiffordComment #16
andrewmacpherson commentedJust reviewing the discussion in these old autofocus issues....
Re: #14 - using the filter isn't the primary use-case of the page. Some other user journeys are equally likely:
Another important journey on the page is: "I'm finished here. I successfully installed the datetime module, and now I want to add a datetime field to a content type." If autofocus puts you in the filter, you need to shift-tab a long way back to the structure link in the toolbar. It's quicker to reach the filter going forwards via the skip-link than it it is to reach the toolbar going backwards from the filter.
If you want to uninstall a module, you have to come via the module installation page. There's no other way of reaching the pages linked in primary tabs.