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)
>>>
>>> -----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
> > > > >


--
Jennison Mark Asuncion
LinkedIn at www.linkedin.com/in/jennison
Follow me on Twitter www.twitter.com/jennison
Organizer, Bay Area Accessibility and Inclusive Design www.meetup.com/a11ybay
Organizer, Accessibility Camp Bay Area www.accessibilitycampbay.org
Co-Founder, Global Accessibility Awareness Day
www.globalaccessibilityawarenessday.org