Usability: Autofocus textfields

You can also do that by adding a tabindex field using #attributes! For example <input type="text" tabindex="0" value="abc">, the form element with the lowest index will get focus on load. It's much more valueable to define a tab order than having a simple (boolean) #autofocus IMO.

I must admit I never used tabindex myself and YES it can be evil ;)
It seems that your code always focuses the first #autofocus field on the page, right? Thats great, because I dont need to ask what happens if there are multiple autofocus fields on a page! I guess this option must/should be used by module developers very carefully. But I like it and it can enhance usability a lot. But I think it needs some more reviews before RTBC.
+1 on the idea and the patch

This is a simple and cleanly coded usability improvement.

The particular forms to add it to is no doubt debatable. The implementations done here, however, seem to make sense.

For consistency with #collapsible and #autocomplete_path, there should be a default #autofocus => FALSE for 'textfield' and 'textarea' in system_elements().

Code looks good and this would be a very useful, yet simple addition.

My only concern, does "autofocus" make more sense then just "focus"? I think the latter might be a better choice...

Do we still use drupal_add_js(.., 'core') ?

+1 for the feature and for applying it across core. This improves usability a lot.

Other places we could apply to:
- User login/register/password form and block
- Search page

When using my Focus module which does the same thing the only drawback I've seen so far is that Opera is a bit slow when applying the focus which has some side effects. E.g. when creating a content type and scrolling down the page fast, it will jump up again when the "autfocous" is applied. I think this is due to the focus being applied after the core javascript (textarea, collapse). Firefox don't have this problem.

In this patch the focus is done first which removes most of the delay. My point is that the order of the (core) javascript files seems to be somewhat important. autofocus.js does come directly after drupal.js, but is that intentional?

+1 for this in core.

quite nice. hope that recent comments are incorporated and we drive towards commit.

I don't know why, but i am seeing apache segfault when adding a term with this patch applied. i don't know why. anyone else seeing this?

in that case, its not ready

Cool stuff, still moving to D7.

Moving all usability issues to Drupal - component usability.

Wonderful feature. I've applied the patch and I really enjoy it so far.

I'll review this more in depth soon.

patch applies cleanly and works very well for all the forms I looked at.

It does mean that drupal.js will get sent to the user more often though. not sure how much of a concern that is.

I think we woiuld be better off if these fields would get autofocus when they are empty. Most browser won't scroll using the arrow key if your cursor is inside a field. That's rather annoying when editing. When adding then sure, you want to start there, it's a very nice feature.

Simple, elegant, and, simply put, it works; however, I completely agree with chx #21 in that autofocus should only take effect if the fields are empty.

Agree with the suggestion in #21. Let's try and get this fixed within two years after opening the issue! :-)

Caught this patch up to head, and made the autofocus only happen if input fields are empty.

And in line with #23, we only have 4 days to get this done ;)

This is awesome! Patch applies with some fuzz on user.module & user.admin.inc, but that's not really a blocker imo.
But really, try adding some terms to a vocabulary, man, a life-saver! Marking as rtbc to get some core commiters attention.

This is a sweet little usability patch! Nice! :D

The discussion I wanted to have in #drupal is whether or not it makes sense to move this behaviour into FAPI so that it's automatic and module developers don't have to manually remember to do this. I can see a lot of follow-up patches resulting from forms going in that are missing this property, and contrib being very spotty about it.

It seems like the logic would be something like:

If this is the first time there's been a text field on this form and it is empty, then toggle its #autofocus property to TRUE.

I am also very, very tired, so it's possible I'm on crack. ;)

Either way though, this also needs a changelog entry. :D So marking CNW.

@Webchick, I understand the logic behind setting the first textfield to autofocus automatically, however, right now in my D7 test site, I have the search box also in my left region. Say I want to add new terms, I *think* (untested though), the autofocus will be set on the textfield of the search form while I really don't want that. My two cents of course, what do others think about this ?

Usability-wise making this default behavior for primary forms is a good idea. It would be quite counter-intuitive if all forms created by core had auto-focusing, but suddenly a form provided by Module X doesn't.

On the other hand, that requires the auto-focusing behavior to detect which form item is the first of the Primary Form. Or we have to make sure that forms like the search field, simplenews subscription field, etc, explicitly set #autofocus = FALSE on their form. In fact, that isn't all that bad, because this would only be tiny subset of the forms compared to the regular forms.

Ok, let's amend the logic:

If this is the first time there's been a text field on this form and it is empty, AND this is the first #autofocus property that's been set this page request, then toggle its #autofocus property to TRUE.

Since search, etc. are in sidebar blocks, they would be rendered after the primary content (I think?) so this could work. Maybe? :)

More or less. But we might only want to autofocus the textfield if it is empty, per #21.

Since search, etc. are in sidebar blocks, they would be rendered after the primary content

Not always, depends on the theme, some themes have the left blockbar before the primary content. Also, some people place the search box in the top theme.
I think it is important that non-main forms like the search-block are actively prohibited from getting the #autofocus property.

On a related note, does somebody have experience with an anchor that is way below, while having an autofocus for something higher up? Does the page get shifted a lot then, or does the anchor have precedence over JS controled focus?

Hm. The only one I can think of is site name on the install form. Ok, how about:

If the form element has its #autofocus explicitly set to TRUE, use it.

Otherwise:

If this is the first time there's been a text field on this form and it is empty, AND this is the first #autofocus property that's been set this page request, then toggle its #autofocus property to TRUE.

:P

Is there any discussion of some version of this still making it into core? If so - probably would be Drupal 8.

Should just be html5 autofocus and fallback to js.

See http://diveintohtml5.org/forms.html

It seems as though the adding the autofocus attribute where it makes sense would be a nice improvement, but there are some potential accessibility issues that need to be worked out. This gist of it is that screen readers will be thrown directly into the form and miss any guidelines, or context that appear before it, outside of the form. This post provides details about the problem and offers a solution using aria-describedby: http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/

I also don't know that a JS fallback makes sense anymore. Browser support for HTML5 autofocus is pretty decent and WebAIM makes a good point about JS preventing those that want to disable this kind of behavior from doing so:

Script-based autofocusing is extremely common today, but suffers from a number of problems, including the fact that there is no way to turn it off. With the autofocus attribute, web browsers and other user agents can give people the ability to disable this feature, either on a specific website or for the entire web.

Not speaking as an accessibility maintainer, but only as a screen-reader user, I can tell you that IMO autofocus is a * very very very * annoying behaviour to have on a page, unless like Google the only purpose of the page is to submit that particular form and there is absolutely no instruction / direction required.

I can get behind autofocus on add terms, and perhaps search form (when it is the page not the block), and perhaps other use-cases, but really I am not a fan of using autofocus on the majority of forms by default.

I have mixed feelings on JS fallback. JS helps to ensure consistency, and I'm not sure if any user really will turn off (or if it is an option) autofocus in there UA. I can't see it being possible to turn autofocus off in assistive tech, based on how it interacts with the accessibility API used in browsers, but I could be wrong about this.

As for aria-describedby, I agree that we should do this, in fact #405360: Use aria-describedby to link form elements with form element descriptions is already oopen. But if the description of the form is outside of the autofocused form element #description then that issue won't solve the problem.

Seems like a won't fix then? Would be a bit weird to special case this, on a few things - will create a rather inconsistent experience?

@bojhan

The experience would be inconsistent between forms for sure, is this necessarily a problem?

Does a user going to a Search page expect focus to be in the search field to start? What about being on the Contact page of a site, where there could potentially be 3 forms (login block, search block, contact form), which would receive autofocus? The user is there to Contact, so it might be nice to land in the first field of the contact form, but this means that a form preamble will be missed by some screen-reader and possibly magnifier users.

If consistency isn't a problem, i.e. users expect autofocus on some forms and not on others, can we come up with a list of forms where we think that autofocus should apply? If consistency is a major problem, i.e. we do not want some forms to autofocus and others to not, then I would say that this is a 'won't fix' for Core, but could be accomplished in contrib.

@Everett I think we can make assumptions for a large number of creation screens (terms, content, fields) but probably not any configuration screens. I am on the fence whether it is a good thing to pursue, primary because on the front-end we cant really assume (people customizing and using different parts of the form as - in contact form, starting with name for example) and basically requiring contrib to define which field receives autofocus (question there even if they do, will they do it consistently?).

I'm gonna go out on a limb and mark this wont fix based on the last few comments. Feel free to reopen if you disagree.

https://www.drupal.org/project/focus module seems to do the job for me, atleast for now. Am curious if this was considered in Drupal 8 or not.

@Gokul N K - this isn't considered an accessibility best practice, but it's totally appropriate for a contrib module.

tagging, just gathering issues which requested autofocus