Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
When you visit the module page you want to enable a module or you want to search for a module. To save time the "Enter module name" field should be focused.
Proposed resolution
Just add the "autofocus" attribute to the field.
User interface changes
The user can see that the field is focused automatically.
Related Issues
#1848064: Allow to filter modules by arbitrary search strings on the Modules page
Comment | File | Size | Author |
---|---|---|---|
#15 | drupal-autofocus_module_search-2096347-15.patch | 726 bytes | mgifford |
#8 | drupal-autofocus_module_search-2096347-8.patch | 819 bytes | yannickoo |
#1 | drupal-autofocus_module_search-2096347-1.patch | 663 bytes | yannickoo |
Screen Shot 2013-09-24 at 00.30.08.png | 23.3 KB | yannickoo |
Comments
Comment #1
yannickooComment #2
yannickooLet's check whether it is okay for screenreaders to focus on that field.
Comment #3
YesCT CreditAttribution: YesCT commentedI think we discussed this and related accessibility issues in some other issue... hm. maybe #1919470: Add a search field to the test overview page
Comment #4
jibran+1 for the change and RTBC for me. We are only adding a simple attribute so I don't think it is a feature request.
Comment #5
mparker17Code looks good.
Manual testing works correctly.
Testbot likes it.
I'd say this is RTBC!
Comment #6
yannickooOh, YesCT was right and this was removed in #1932958: Cursor shouldn't be moved to module search field.
Let's discuss in the other issue because we have to figure out how we can make it easier for blind people.
Comment #7
falcon03 CreditAttribution: falcon03 commentedFrom a screen reader user point of view this is "won't fix". See the other issue for further details. However, I'm setting this issue to "needs work" to let people discuss about it.
Basically, the issue is that if the cursor is moved to that form field a screen reader user will miss the help text placed at the begin of the modules page and this is of course undesirable.
Comment #8
yannickooI talked with jessebeach and she showed me the
aria-describedby
attribute and I think it is a good solution to have the help text included.Comment #9
mparker17Code looks good.
Manual-testing suggests code works as-designed.
Comment #10
falcon03 CreditAttribution: falcon03 commentedThe help text does not only explain what the search field is used for. So using aria-describedby looks inappropriate to me.
In fact, if I remember correctly, the help text contains links to d.o and various handbook pages... If the search field is auto-focused, even if the text is read aloud because of aria-describedby, a blind user would have to browse the page to find the links and eventually click on them. And browsing a page starting from the middle of it can be really disorienting.
Comment #11
BarisW CreditAttribution: BarisW commentedWhat if we just improve the Title text on the element?
Now: "Enter a part of the module name or description to filter by."
Suggestion: "The module overview can be filtered by entering a part of the module name or its description in this field."
Then we can remove the aria-describedby attribute and still focus on the field.
Comment #12
Bojhan CreditAttribution: Bojhan commentedFYI, this should not go back to RTBC until signoff of a11y team.
Comment #13
nod_" To save time" is not a good justification for bypassing a11y gate. that's a won't fix for me.
Comment #14
BarisW CreditAttribution: BarisW commentedComment #14.0
BarisW CreditAttribution: BarisW commentedLinked related issue.
Comment #15
mgiffordI've added a question for that here http://webmasters.stackexchange.com/questions/64966/when-is-it-appropria...
I'm trying to find generalized patters for this to help us decide how to move this forward.
Closes I've seen thus far is from Jared stating
Right now the code is:
Bruce suggested that aria-describedby could be used to make this more understandable http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/
One of @falcon03's concern was that the help wasn't relevant.
It is really the same issue as per /search/node as well.
Comment #16
mgiffordThere is autofocus in:
/user
/user/password
Applied with:
But not:
/user/register
/search/node
Comment #17
mgiffordThis was already removed from the javascript, but doing it with HTML5 does allow it to be controlled by the assistive technology.
Comment #18
mgiffordComment #19
falcon03 CreditAttribution: falcon03 commentedAs @mgifford reported from stack exchange, autofocus should be used only when its obvious what a certain field should be used for and that field is the most important element of a page. That's not the case of the search field on the admin modules page, though.
Mike suggested that using HTML 5 autofocus attribute AT can be configured to not use it.
Offering a pleasant user experience to AT users is responsibility of a website, not of a screen reader. Not to mention the fact that there are certain situations where you could find autofocus useful, even if you use a screen reader. And I could easily suppose that enabling/disabling autofocus support from the screen reader configuration could just be a global flag, so you couldn't fine-tune autofocus support to your needs. Long story short, from a screen reader user point of view let's close this issue as won't fix...
Comment #20
nod_Let's kill it.
Comment #21
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedTags...
- Tidying up the "needs accessibility review" list
- Gathering issues which requested autofocus