WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: programmatically setting focus on page load

for

From: deborah.kaplan
Date: Jul 2, 2015 8:06AM

I think the key thing here is "if the primary purpose of the page is to fill out the form". It is absolutely true that on a simple page where 99.9% of users are going to be hitting the form field and nothing else -- a search engine home page, for example -- keeping the focus in the search box makes good sense. However, far too many developers have expanded that to not think about the other use cases of their page.

Autofocusing to a search field on a search results page, as in the WorldCat example I linked below, is exactly the *wrong* behavior. On a search results page, there are reasonable odds the search was successful, and user's goal on that page is to navigate through the search results. An auto focused form field in that case -- which is a very, very common design pattern -- means that a keyboard user can't scroll through the page to navigate the search results without first leaving the form field. It means that a screen reader user, instead of having the focus on a useful page element, like, say, a heading reading "Search results (32 titles)," has the page reload with simply another indication that they are in a form, and no particular indication of success.

I will note that the default Google web interface workaround is only a mild improvement from a keyboard user's point of view. Google's implementation of instant search doesn't put focus in the form field (allowing page up/down, arrow keys, and any chorded keystrokes), but captures any regular keys. Keyboard users are likely to be using many of the keys on the keyboard for navigation or other functionality, and Google instant search is such an unusual design that is deeply disruptive to a keyboard user who is used in other site designs. But to give Google credit, you can disable instant search.

Deborah Kaplan

On Thu, 2 Jul 2015, Moore,Michael (HHSC) wrote:

> I don't believe that setting focus on the first appropriate form field on a page violates 2.4.3 if the primary purpose of the page is to fill out the form then this is probably the best place to set focus from the user standpoint.
>
> Screen readers will need to exit forms mode (or whatever the terminology is for the particular screen reader) to exit the form and do something else but presumably getting to the form was a deliberate action on their part. If not there was a problem on the previous page either a violation of guideline 3.2 (predictable) or of 2.4.4(AA) link purpose (in context).
>
> If you cannot leave the form field to do something else then you have a keyboard trap. 2.1.2 (A). I think that we can stretch this to include not being able to access preceding content in a mobile app.
>
> Finally if there is not a clear indication that you are focused on the field the violation is 2.4.7 (AA).
>
> Placing focus on the top of every page in a web application that spans multiple interfaces would really reduce the efficiency for everyone. Keyboard users would need to click on a skip to content link, mouse users would need to scroll to the form and click on the first field (this could really make things difficult for screen magnifier users) and screen readers would need to use either the skip link or quick keys to get to the first field. By placing focus on the first appropriate field then everyone becomes more efficient.
>
> Note: The first field on the page may not be the most appropriate place to put focus. The business process may dictate a different work flow. What is important is that the focus order properly matches that workflow and that focus location is clearly indicated.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
> (512) 574-0091 (Cell)
>
>