WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: programmatically setting focus on page load

for

From: deborah.kaplan@suberic.net
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)
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of <EMAIL REMOVED>
> Sent: Wednesday, July 01, 2015 6:30 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] programmatically setting focus on page load
>
> Depending on the page, it can be argued to violate 2.4.3, Focus order. If you arrive in the middle of the page, that's an illogical focus order.
>
> Personally I find it always to be a keyboard/voice accessibility roadblock unless (1) all content is visible without needing to scroll down, (2) the form is the only thing you're likely do on the page, and (3) on a mobile screen, someone will not have a problem clicking a part of the screen that is not the input form field.
>
> When you're using a keyboard, and you arrive in a page that has autofocus, you suddenly discover that none of your usual commands are working (especially if the visual focus is not obvious). You can't page down, you can select any page elements, you can't move around the page until you realize that you are in a focused text box. On a mobile device, you load the page and are automatically in a keyboard view, which might take up most of the page.
>
> Here's an example of a page with multiple many, many links which you might want to activate, but where the form field is automatically activated on every page load or form submission: http://www.worldcat.org/search?qt=worldcat_org_all&;q=smekday
>
> Deborah Kaplan
>
> On Wed, 1 Jul 2015, Paul J. Adam wrote:
>
>> Hey Jennison, if it's the login page or the home page and the main task for a user is to login to the site then that makes sense as the fastest way to get the user into their main goal.
>>
>> I use the HTML5 autofocus attribute on my personal contact form so
>> that puts your focus there automatically because I decided that's the
>> main goal of that page. http://pauljadam.com/#/contact
>> <http://pauljadam.com/#/contact>;
>>
>> Autofocus is much better than using positive tabindex values which break the focus order most times.
>>
>> So no I would not call it a WCAG Success Criterion failure.
>>
>> Paul J. Adam
>> Accessibility Evangelist
>> www.deque.com
>>
>> Join us at our Mobile Accessibility "Bootcamp!"
>> August 6-7 in Austin Texas
>> https://dequeuniversity.com/events/2015/mobile
>> Topics include responsive web design, native apps, & more
>>
>>> On Jul 1, 2015, at 5:10 PM, Jennison Mark Asuncion < <EMAIL REMOVED> > wrote:
>>>
>>> Hi,
>>>
>>> If a page loads, and focus is programmatically set, say to go
>>> directly to a User Name field (i.e., a screen reader user would be
>>> unaware of any content above), does that make the page nonconformant with WCAG?
>>> My gut is saying it does, but I am unsure and need a sanity check and
>>> the guideline reference (if my gut is right).
>>>
>>>
>>>
>>> Jennison
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >
> --
> > > > > > > --