E-mail List Archives
Re: programmatically setting focus on page load
From: Robert Fentress
Date: Jul 2, 2015 10:47AM
- Next message: Mickey Williamson: "Anyone using PaypalAATT?"
- Previous message: Morin, Gary (NIH/OD) [E]: "Re: Is Vimeo screenreader accessible"
- Next message in Thread: Jennison Mark Asuncion: "Re: programmatically setting focus on page load"
- Previous message in Thread: deborah.kaplan@suberic.net: "Re: programmatically setting focus on page load"
- View all messages in this Thread
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)
>>
>>
- Next message: Mickey Williamson: "Anyone using PaypalAATT?"
- Previous message: Morin, Gary (NIH/OD) [E]: "Re: Is Vimeo screenreader accessible"
- Next message in Thread: Jennison Mark Asuncion: "Re: programmatically setting focus on page load"
- Previous message in Thread: deborah.kaplan@suberic.net: "Re: programmatically setting focus on page load"
- View all messages in this Thread