WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: programmatically setting focus on page load

for

From: Robert Fentress
Date: Jul 2, 2015 10:47AM

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)
>>
>> -----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
>>> >>>
>>
>> --
>> >> >> at http://webaim.org/discussion/archives
>> >> >> >> >> >>
>
> --
> > > > >



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061