E-mail List Archives
Thread: programmatically setting focus on page load
Number of posts in this thread: 8 (In chronological order)
From: Jennison Mark Asuncion
Date: Wed, Jul 01 2015 4:10PM
Subject: programmatically setting focus on page load
No previous message | Next message →
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
From: Greg Gamble
Date: Wed, Jul 01 2015 4:16PM
Subject: Re: programmatically setting focus on page load
← Previous message | Next message →
As long as they could navigate back up, it still should conform. Bad habit, but a lot of sites do it.
Greg
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jennison Mark Asuncion
Sent: Wednesday, July 01, 2015 3:11 PM
To: webaim-forum
Subject: [WebAIM] programmatically setting focus on page load
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
From: Paul J. Adam
Date: Wed, Jul 01 2015 4:39PM
Subject: Re: programmatically setting focus on page load
← Previous message | Next message →
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 ADDRESS 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
> > > >
From: deborah.kaplan@suberic.net
Date: Wed, Jul 01 2015 5:29PM
Subject: Re: programmatically setting focus on page load
← Previous message | Next message →
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 ADDRESS 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
>> >> >> >> >
> > > > --
From: Moore,Michael (HHSC)
Date: Thu, Jul 02 2015 7:43AM
Subject: Re: programmatically setting focus on page load
← Previous message | Next message →
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 ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS 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 ADDRESS 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
> --
From: deborah.kaplan@suberic.net
Date: Thu, Jul 02 2015 8:06AM
Subject: Re: programmatically setting focus on page load
← Previous message | Next message →
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 ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS 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 ADDRESS 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
>> >
> --
> > > > > > > --
From: Robert Fentress
Date: Thu, Jul 02 2015 10:47AM
Subject: Re: programmatically setting focus on page load
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED = ] On
>> Behalf Of = EMAIL ADDRESS 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 ADDRESS 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
From: Jennison Mark Asuncion
Date: Thu, Jul 02 2015 10:22PM
Subject: Re: programmatically setting focus on page load
← Previous message | No next message
Thanks all for the help.
Jennison
On 7/2/15, Robert Fentress < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ] On
>>> Behalf Of = EMAIL ADDRESS 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 ADDRESS 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