WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: programmatically setting focus on page load

for

From: Jennison Mark Asuncion
Date: Jul 2, 2015 10:22PM

Thanks all for the help.

Jennison

On 7/2/15, Robert Fentress < <EMAIL REMOVED> > wrote:
> Here is a link to a previous discussion of this issue on the list:
> http://webaim.org/discussion/mail_thread?threadf12
>
> Best,
> Rob
>
> On Thu, Jul 2, 2015 at 10:06 AM, < <EMAIL REMOVED> > wrote:
>
>> 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)
>>>
>>>