When is it appropriate to add the HTML5 “autofocus” attribute to a page?

Question

For usability it can be useful to autofocus on something like the search input form on a search page.

Where the primary purpose of a page is to search or add content, it can be appropriate to assume that is what you want to do and help you get there as quickly as possible.

In Drupal 8 we're struggling with this here: https://drupal.org/node/2096347

Note that this isn't just a Drupal issue, but certainly something that we're looking at.

There are some great descriptions:

• http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/
• http://webaim.org/blog/future-web-accessibility-html5-input-extensions/
• https://stackoverflow.com/questions/2180645/is-automatically-assigning-focus-bad-for-accessibility/2180679#2180679

Unfortunately, there are no guidelines for when to use HTML5's autofocus properly.

As @Jared says "Will your users know that there going to a page with a form, and does there need to be any descriptive text you should read before filling out the form? I'm a screen reader user and it can be annoying having focused put in random fields. It's clear why your focus winds up in the Google search box so that doesn't bother me. If my focus were automatically placed in the answer edit field every time I viewed a question on Stackoverflow I would be annoyed since I'd have to force my screen reader to navigate away from the form field and to the top of the page."

But is that enough?

We want to look at usability and accessibility of autofocus. The page needs to be able to meet WCAG 2.0 AA requirements.

Answer 1

I have nothing but intuition to back this up, but the following heuristic might work:

Is there one absolutely unambiguous point of attention on your page? An area for which you can say with absolute certainty that your user will look at as soon as the page loads? Is the main element in that area a form with either one input element or a very clear sequence?

If the answer is yes to all, you can autofocus on the first (and preferably, only) element of the form. If not, you risk violating the principle of least surprise. If your user came to the page to read an article and his shortcuts don't work because you autofocused the search box, it's a UX failure.

The form in question needs to be the single most common reason for visiting the page, with all other use cases far behind.

You can relax this a little bit by saying that the form needs to be in the locus of attention but not the focus. For instance, on the Google results page, the main use case is to review the search results, but the search box is still autofocused (though without a cursor). This doesn't cause a big problem, since the user will still notice the search box changing if she types. If the search box were smaller, and in the sidebar, this might become a problem. Notice also that if you scroll down and type, the page scrolls back up to reveal the search box to show the user where they're actions are causing an effect.

So the Google results page gives us an edge case where the autofocused element does not provide the maine use case of the page, but it does provide an important use case, and the autofocus is implemented carefully, to minimize surprise.

Answer 2

Keep in mind accessibility. Autofocus can be a huge accessibility hurdle, but is also quite useful in certain situations.

It's useful when there's a lot of stuff on the page that a person using a screen reader would not want to have to deal with to get to the point of the current visual. A typical scenario for this is a modal. When a modal appears, you will wan to auto-focus on said modal so the screen reader knows that the modal is the primary focus at the moment.

Otherwise, avoid it for anything short of a page that is designed to do only one thing and one thing only and people only do that one thing. The Google search page is perhaps the only public example I can think of. There's likely many private examples such as a custom enterprise data tool with a query page.