WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Initial focus on search field?

for

Number of posts in this thread: 14 (In chronological order)

From: Robert Fentress
Date: Mon, Sep 22 2014 1:34PM
Subject: Initial focus on search field?
No previous message | Next message →

Hello, all.

Do you have a sense for what is best practice concerning where focus
should initially be set on pages in complex web sites that contain a
prominent global search field on every page?

For our site, the search field appears after an initial set of
navigation links, and at this point, changing the order of the menu
links and the search field in the code isn't feasible. An original
design constraint was that the search field be automatically given
focus upon page load, since usability studies showed that most people
preferred using search to navigate the site.

However, I was concerned that this could present problems for screen
reader users who might not notice the list of links before the search
field. This does seem to be a common pattern on the web though, so I
wonder if screen reader users would expect (and perhaps prefer) this
behavior.

Initially though, I recommended against explicitly setting focus.
Instead, I suggested best practice would be to add, at the start of
the page, a single skip link to the main content, and to create
landmark regions for the main page areas (including role="search" for
the where the search field appears). Screen reader users could then
use landmark navigation to quickly get to the search field.

The developer has gotten pushback though, because of the original
design requirement mandating that focus be set to the initial search
field. He has tried to be creative by not initially setting focus,
instead making it so that, as soon as the user begins typing, focus is
set to the search field. So a tab takes the user to the first link in
the menu on the page, but typing "a search string" automatically moves
the user to the search field and enters the text typed into the field.
This is problematic, though, because some keys are reserved as page
navigation commands by some screen readers, such that typing "b" takes
you to the first button on the page, etc.

At this point, given the constraints we're operating under, I'm
leaning towards just telling him to set focus to the search field,
with the thought that screen reader users may expect this sort of
thing and figure things out, especially given the landmarks provided.
What do you think?

Thanks,
Rob

--
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: deborah.kaplan@suberic.net
Date: Mon, Sep 22 2014 1:43PM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

Please don't set the focus to the search field. The only circumstances under which it is good practice to set the focus to the search field it if there is absolutely nothing else that a keyboard or screen reader user might want to do on that page.

When you set the focus to the search field:

1. The keyboard user shows up on a new page, and unexpectedly discovers that most of the regular keyboard controls (e.g. page up, page down) don't work, and if they start tabbing around the page they are not tabbing from the top left (a problem which is made far worse if the visual focus indicator for the keyboard is not very easy to see).

2. The screen reader user doesn't get the benefit of hearing any of the information at the top of the page, including the skip links that might take them to a different location on the page than the search field, or any of the early headers that were navigation information.

3. The screen magnification user doesn't see the top left of the page, and doesn't know where they are and what information they have skipped, and whether they need to scroll back and find it.

It is becoming an increasingly common practice to let some field or another grab the keyboard focus. And as a keyboard user, I have to say, the percentage of pages on which I don't find it disruptive to my browsing experience is a comfortable 0; I turn it off when ever the site gives me the ability to do so.

Deborah Kaplan


On Mon, 22 Sep 2014, Robert Fentress wrote:

> Hello, all.
>
> Do you have a sense for what is best practice concerning where focus
> should initially be set on pages in complex web sites that contain a
> prominent global search field on every page?
>
> For our site, the search field appears after an initial set of
> navigation links, and at this point, changing the order of the menu
> links and the search field in the code isn't feasible. An original
> design constraint was that the search field be automatically given
> focus upon page load, since usability studies showed that most people
> preferred using search to navigate the site.
>
> However, I was concerned that this could present problems for screen
> reader users who might not notice the list of links before the search
> field. This does seem to be a common pattern on the web though, so I
> wonder if screen reader users would expect (and perhaps prefer) this
> behavior.
>
> Initially though, I recommended against explicitly setting focus.
> Instead, I suggested best practice would be to add, at the start of
> the page, a single skip link to the main content, and to create
> landmark regions for the main page areas (including role="search" for
> the where the search field appears). Screen reader users could then
> use landmark navigation to quickly get to the search field.
>
> The developer has gotten pushback though, because of the original
> design requirement mandating that focus be set to the initial search
> field. He has tried to be creative by not initially setting focus,
> instead making it so that, as soon as the user begins typing, focus is
> set to the search field. So a tab takes the user to the first link in
> the menu on the page, but typing "a search string" automatically moves
> the user to the search field and enters the text typed into the field.
> This is problematic, though, because some keys are reserved as page
> navigation commands by some screen readers, such that typing "b" takes
> you to the first button on the page, etc.
>
> At this point, given the constraints we're operating under, I'm
> leaning towards just telling him to set focus to the search field,
> with the thought that screen reader users may expect this sort of
> thing and figure things out, especially given the landmarks provided.
> What do you think?
>
> Thanks,
> Rob
>
>

--

From: Don Mauck
Date: Mon, Sep 22 2014 1:57PM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

If they are JAVA scripts with automatic evaluations such as: a drop down with options such as one week< last 30 day, ETC. However my next question is if ARIA is used how does a keyboard user only do this easily, using ARIA? including the ARIA code. .

-----Original Message-----
From: Robert Fentress [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, September 22, 2014 1:35 PM
To: WebAIM Discussion List
Subject: [WebAIM] Initial focus on search field?

Hello, all.

Do you have a sense for what is best practice concerning where focus should initially be set on pages in complex web sites that contain a prominent global search field on every page?

For our site, the search field appears after an initial set of navigation links, and at this point, changing the order of the menu links and the search field in the code isn't feasible. An original design constraint was that the search field be automatically given focus upon page load, since usability studies showed that most people preferred using search to navigate the site.

However, I was concerned that this could present problems for screen reader users who might not notice the list of links before the search field. This does seem to be a common pattern on the web though, so I wonder if screen reader users would expect (and perhaps prefer) this behavior.

Initially though, I recommended against explicitly setting focus.
Instead, I suggested best practice would be to add, at the start of the page, a single skip link to the main content, and to create landmark regions for the main page areas (including role="search" for the where the search field appears). Screen reader users could then use landmark navigation to quickly get to the search field.

The developer has gotten pushback though, because of the original design requirement mandating that focus be set to the initial search field. He has tried to be creative by not initially setting focus, instead making it so that, as soon as the user begins typing, focus is set to the search field. So a tab takes the user to the first link in the menu on the page, but typing "a search string" automatically moves the user to the search field and enters the text typed into the field.
This is problematic, though, because some keys are reserved as page navigation commands by some screen readers, such that typing "b" takes you to the first button on the page, etc.

At this point, given the constraints we're operating under, I'm leaning towards just telling him to set focus to the search field, with the thought that screen reader users may expect this sort of thing and figure things out, especially given the landmarks provided.
What do you think?

Thanks,
Rob

--
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: Jukka K. Korpela
Date: Mon, Sep 22 2014 2:06PM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

Om 2014-09-22 22:43, = EMAIL ADDRESS REMOVED = wrote:

> Please don't set the focus to the search field. The only circumstances
> under which it is good practice to set the focus to the search field it
> if there is absolutely nothing else that a keyboard or screen reader
> user might want to do on that page.

I couldn’t agree more. But if ypu really have page *for* a site-wide
search only, then <input type=search autofocus ...> might make sense.

Yucca

From: Robert Fentress
Date: Mon, Sep 22 2014 2:15PM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

Thanks, Deborah.

Yeah, that was my thought as well. I'm just not sure how
accommodating the team is going to be, what with the requirements
given to them by other stakeholders. I was hoping there might be some
creative accessibility workaround for this increasingly common
practice, or that screen reader users' expectations about things might
have changed as a result of how frequently this technique is used.

If I can't get them to budge on this, how bad would it be to provide a
hint to screen reader users that there was content before the search
field by using something an aria live region. A cookie could be set
so that the notification would only be provided the first time this
happened. Strikes me as a bad hack, but I'm trying to give them
options, if the preferred solution is not an option.

This is something I've wondered about generally: Are there instances
where it is best practice to provide invisible hints to screen reader
users about the way complex sites function or does the extra verbosity
of this and the possibility that such notices may not be updated as
pages change, pretty much always make this a bad idea?

Best,
Rob

On Mon, Sep 22, 2014 at 3:43 PM, < = EMAIL ADDRESS REMOVED = > wrote:
> Please don't set the focus to the search field. The only circumstances under
> which it is good practice to set the focus to the search field it if there
> is absolutely nothing else that a keyboard or screen reader user might want
> to do on that page.
>
> When you set the focus to the search field:
>
> 1. The keyboard user shows up on a new page, and unexpectedly discovers that
> most of the regular keyboard controls (e.g. page up, page down) don't work,
> and if they start tabbing around the page they are not tabbing from the top
> left (a problem which is made far worse if the visual focus indicator for
> the keyboard is not very easy to see).
>
> 2. The screen reader user doesn't get the benefit of hearing any of the
> information at the top of the page, including the skip links that might take
> them to a different location on the page than the search field, or any of
> the early headers that were navigation information.
>
> 3. The screen magnification user doesn't see the top left of the page, and
> doesn't know where they are and what information they have skipped, and
> whether they need to scroll back and find it.
>
> It is becoming an increasingly common practice to let some field or another
> grab the keyboard focus. And as a keyboard user, I have to say, the
> percentage of pages on which I don't find it disruptive to my browsing
> experience is a comfortable 0; I turn it off when ever the site gives me the
> ability to do so.
>
> Deborah Kaplan
>
>
>
> On Mon, 22 Sep 2014, Robert Fentress wrote:
>
>> Hello, all.
>>
>> Do you have a sense for what is best practice concerning where focus
>> should initially be set on pages in complex web sites that contain a
>> prominent global search field on every page?
>>
>> For our site, the search field appears after an initial set of
>> navigation links, and at this point, changing the order of the menu
>> links and the search field in the code isn't feasible. An original
>> design constraint was that the search field be automatically given
>> focus upon page load, since usability studies showed that most people
>> preferred using search to navigate the site.
>>
>> However, I was concerned that this could present problems for screen
>> reader users who might not notice the list of links before the search
>> field. This does seem to be a common pattern on the web though, so I
>> wonder if screen reader users would expect (and perhaps prefer) this
>> behavior.
>>
>> Initially though, I recommended against explicitly setting focus.
>> Instead, I suggested best practice would be to add, at the start of
>> the page, a single skip link to the main content, and to create
>> landmark regions for the main page areas (including role="search" for
>> the where the search field appears). Screen reader users could then
>> use landmark navigation to quickly get to the search field.
>>
>> The developer has gotten pushback though, because of the original
>> design requirement mandating that focus be set to the initial search
>> field. He has tried to be creative by not initially setting focus,
>> instead making it so that, as soon as the user begins typing, focus is
>> set to the search field. So a tab takes the user to the first link in
>> the menu on the page, but typing "a search string" automatically moves
>> the user to the search field and enters the text typed into the field.
>> This is problematic, though, because some keys are reserved as page
>> navigation commands by some screen readers, such that typing "b" takes
>> you to the first button on the page, etc.
>>
>> At this point, given the constraints we're operating under, I'm
>> leaning towards just telling him to set focus to the search field,
>> with the thought that screen reader users may expect this sort of
>> thing and figure things out, especially given the landmarks provided.
>> What do you think?
>>
>> Thanks,
>> Rob
>>
>>
>
> --
> > > --
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: deborah.kaplan@suberic.net
Date: Mon, Sep 22 2014 2:41PM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

> If I can't get them to budge on this, how bad would it be to provide a
> hint to screen reader users that there was content before the search
> field by using something an aria live region.

This won't help keyboard users, though, and it won't help magnification users.

For keyboard users, if this is absolutely unavoidable, at least make sure your visual keyboard focus indicator

(1) works (never vanishes into hidden menus, etc. -- more common than you'd think)

(2) is big and bold and obvious. WebAIM's comes to mind, or http://www.deque.com/, or http://www.knowbility.org/ .

For magnification users, I'm not sure what fix would work.

> This is something I've wondered about generally: Are there instances
> where it is best practice to provide invisible hints to screen reader
> users about the way complex sites function or does the extra verbosity
> of this and the possibility that such notices may not be updated as
> pages change, pretty much always make this a bad idea?

The risk here is also that you end up thinking that only screen reader users have accessibility needs, like having skip links which are only available to screen reader users even though one of the major use cases is magnification users.

Deborah Kaplan

From: Don Mauck
Date: Mon, Sep 22 2014 2:47PM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

The biggest problem we face is that most developers who don't understand accessibility think that placing focus on the first editable field is a good idea when in fact, it is a bad idea, even for keyboard users. From what I've been told a keyboard can have no cursor focus, that gives them that "flying blind".

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Monday, September 22, 2014 2:41 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Initial focus on search field?

> If I can't get them to budge on this, how bad would it be to provide a
> hint to screen reader users that there was content before the search
> field by using something an aria live region.

This won't help keyboard users, though, and it won't help magnification users.

For keyboard users, if this is absolutely unavoidable, at least make sure your visual keyboard focus indicator

(1) works (never vanishes into hidden menus, etc. -- more common than you'd think)

(2) is big and bold and obvious. WebAIM's comes to mind, or http://www.deque.com/, or http://www.knowbility.org/ .

For magnification users, I'm not sure what fix would work.

> This is something I've wondered about generally: Are there instances
> where it is best practice to provide invisible hints to screen reader
> users about the way complex sites function or does the extra verbosity
> of this and the possibility that such notices may not be updated as
> pages change, pretty much always make this a bad idea?

The risk here is also that you end up thinking that only screen reader users have accessibility needs, like having skip links which are only available to screen reader users even though one of the major use cases is magnification users.

Deborah Kaplan

From: deborah.kaplan@suberic.net
Date: Mon, Sep 22 2014 2:51PM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

It is an actively terrible thing for this keyboard user. I rely heavily on Mouseless Browsing and keyboard builtins. Focus capture often means I'm blankly dictating/typing my navigation commands, frustrated because nothing is working, and never notice that the wee search box off in the top right has been capturing all of my keystrokes. And yes, cursor focus, when present, is usually very difficult to see.

Deborah Kaplan

On Mon, 22 Sep 2014, Don Mauck wrote:

> The biggest problem we face is that most developers who don't understand accessibility think that placing focus on the first editable field is a good idea when in fact, it is a bad idea, even for keyboard users. From what I've been told a keyboard can have no cursor focus, that gives them that "flying blind".

From: Mallory van Achterberg
Date: Tue, Sep 23 2014 4:20AM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

On Mon, Sep 22, 2014 at 03:34:40PM -0400, Robert Fentress wrote:
> ...since usability studies showed that most people
> preferred using search to navigate the site.

More recent research has shown that this differs for sighted users.
Whether they prefer search or navigation depends in part on how
prominent the search field is (regardless of how good or bad the
site's internal search engine is)[1]. If it's a site where people
regularly return (forums, internal product ordering site) then
eventually people choose one or the other based on which one seems
to work. If search sucks on this site, the autofocus is then
*anti* user-friendly.

On a site where search is the main focus/point of the site, you
can maybe get away with it, even with a screen magnifier. Any other
kind of site, these problems caused by the original design
requirements are not adding much benefit.

> The developer has gotten pushback though, because of the original
> design requirement mandating that focus be set to the initial search
> field.

Maybe they should strongly re-evaluate that requirement. If they
still want it, they ought to sign something on paper stating they
are aware that many types of users are actively harmed by this and
that they're totally okay with that.

On the WebAIM page[2] they have this:
"Script-based autofocusing is extremely common today, but suffers from a number of problems, including the fact that there is no way to turn it off. With the autofocus attribute, web browsers and other user agents can give people the ability to disable this feature, either on a specific website or for the entire web."

I'm still waiting for this special ability web browsers are supposed
to have given me (the ability to turn it off). So to me, this is a
reason not to use (any kind of) autofocus. The HTML version does avoid
some of the issue people get with Javascripted autofocus, namely that
many of us have already started typing and are a few inputs further
before all that addThis and shareThat and social BS plugins have finally
let the page finish loading and whoop! now your focus is back to the
first, and you only realised this when you notice the mangled garbage
you've been typing in there.

HTML5Doctor[3] recommends: "However, we only recommend using it for pages whose sole purpose is the form (like Google) to prevent the usability issues."

This suggests usbility issues are a known thing, though I'd love
Baymard or someone to explicitly test this and write a report.

A handy list to offer the company:
- backspace to go back a page breaks (there is a script floating
around to fix this but only this)
- arrow scrolling the page breaks (doesn't matter so much if the page
is so short that it doesn't scroll)
- when leaving the page, coming back to it does not remember the last
place your cursor was, meaning each and every page you return to with
this, you start at the top (assuming the control is at the top). This
one hits mouse uses as well.
- regarding the above, if the search form is *not* at the top, everyone
gets the scroll-ride down to wherever it is. This is way worse for a
magnifier user (you get to see the browser scrolling down, bleh, so
it's not like you don't know you've been moved there, but then you get
to try to figure out how to get to where you want).
- the screen reader issue is already known

I think having people sign paper stating a list of grievances is a
good thing. It puts the issues on something tangible, and it makes
their decision have to have more thought.

They may still decide that they want the autofocus, but at least it's
done with knowledge rather than "we heard a story once that a search
engine improved its usability by autofocussing on the search input".

[1]http://baymard.com/blog/search-field-design
[2]http://webaim.org/blog/future-web-accessibility-html5-input-extensions/
[3]http://html5doctor.com/html5-forms-introduction-and-new-attributes/

From: Jonathan Avila
Date: Tue, Sep 23 2014 6:21AM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

> It is an actively terrible thing for this keyboard user.

For pages where the primary focus is searching or logging into an account I find search fields that are auto focused amazingly helpful and effective. Having my focus placed in the field rather than trying to locate the mouse pointer and click is more effective for me.

Without focus being placed in the search or username field the keyboard only user would have much difficulty navigating to the search or username field.

As you and others have said having a visual indicator of keyboard focus is critical and I agree that most pages should not have auto focus unless immediate input is the core goal of the page. Another location where auto focus could be useful is when you are completing a form that has multiple steps on different pages and the next logical action after moving to the next step is to provide input on next page.

> focus on the first editable field is a good idea when in fact, it is a bad idea, even for keyboard users. From what
> I've been told a keyboard can have no cursor focus, that gives them that "flying blind".

If focus is not set on a page then there is no visual indicator of keyboard focus either. Pressing tab will take the user to the first interactive element in the focus order. So this could also be seen as an issue for certain people too. In general browsers should provide better keyboard support for keyboard only users -- this has historically been a weak area in my opinion.

Regarding screen reader users, there are keystrokes for screen reader users to quickly jump back to the top of the page such as control+home -- thus screen reader users have methods available to move around the page more effectively than keyboard only users. For keyboard only users, pressing control+home or even home doesn't reset the focused control it merely scrolls the screen. One trick that works in Firefox and IE for keyboard only users is to search for text and then press tab -- this will move to the focus to the interactive control after what was searched for. This trick however does not work in Chrome.

Jonathan

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Monday, September 22, 2014 4:51 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Initial focus on search field?

It is an actively terrible thing for this keyboard user. I rely heavily on Mouseless Browsing and keyboard builtins. Focus capture often means I'm blankly dictating/typing my navigation commands, frustrated because nothing is working, and never notice that the wee search box off in the top right has been capturing all of my keystrokes. And yes, cursor focus, when present, is usually very difficult to see.

Deborah Kaplan

On Mon, 22 Sep 2014, Don Mauck wrote:

> The biggest problem we face is that most developers who don't understand accessibility think that placing focus on the first editable field is a good idea when in fact, it is a bad idea, even for keyboard users. From what I've been told a keyboard can have no cursor focus, that gives them that "flying blind".

From: Tim Harshbarger
Date: Tue, Sep 23 2014 7:00AM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

I will offer a dissenting viewpoint.

There is nothing inherently inaccessible about setting the focus to a specific field on a page.

It isn't a problem for screen reader users because screen readers don't even always start reading from the top of the page when focus isn't set to a field. I also think that, if a screen reader has spent much time on the web, they won't think a search field or any other field is likely to be the first item on the page.

It sounds like the problem for keyboard users is not so much setting focus to a field as much as it is ensuring a keyboard user knows where the focus is.

Certainly, it sounds like setting focus to a specific field might sometimes cause additional annoyance to keyboard users, but I'm not sure that is the same as being an accessibility issue. That sounds more like a usability issue. However, at the same time, it sounds like the reason for setting focus to a field is in order to make the user interface more usable.

I would actually tell the developer not to do any special kind of coding. Just set focus to the field and don't hide any focus indicators.

Thanks!
Tim


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Monday, September 22, 2014 2:35 PM
To: WebAIM Discussion List
Subject: [WebAIM] Initial focus on search field?

Hello, all.

Do you have a sense for what is best practice concerning where focus
should initially be set on pages in complex web sites that contain a
prominent global search field on every page?

For our site, the search field appears after an initial set of
navigation links, and at this point, changing the order of the menu
links and the search field in the code isn't feasible. An original
design constraint was that the search field be automatically given
focus upon page load, since usability studies showed that most people
preferred using search to navigate the site.

However, I was concerned that this could present problems for screen
reader users who might not notice the list of links before the search
field. This does seem to be a common pattern on the web though, so I
wonder if screen reader users would expect (and perhaps prefer) this
behavior.

Initially though, I recommended against explicitly setting focus.
Instead, I suggested best practice would be to add, at the start of
the page, a single skip link to the main content, and to create
landmark regions for the main page areas (including role="search" for
the where the search field appears). Screen reader users could then
use landmark navigation to quickly get to the search field.

The developer has gotten pushback though, because of the original
design requirement mandating that focus be set to the initial search
field. He has tried to be creative by not initially setting focus,
instead making it so that, as soon as the user begins typing, focus is
set to the search field. So a tab takes the user to the first link in
the menu on the page, but typing "a search string" automatically moves
the user to the search field and enters the text typed into the field.
This is problematic, though, because some keys are reserved as page
navigation commands by some screen readers, such that typing "b" takes
you to the first button on the page, etc.

At this point, given the constraints we're operating under, I'm
leaning towards just telling him to set focus to the search field,
with the thought that screen reader users may expect this sort of
thing and figure things out, especially given the landmarks provided.
What do you think?

Thanks,
Rob

--
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: Michael Bullis, Executive Director, The IMAGE Center of Maryland
Date: Tue, Sep 23 2014 7:24AM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

As a user and not a developer, I too think it's a usability issue. If the
way you want visual people to use the site is by starting them at the
searchbox, then do it for nonvisual users as well. Google, back in earlier
iterations, use to set the focus to the searchbox automatically. I found it
very helpful, since that's where I wanted to go mostly.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tim Harshbarger
Sent: Tuesday, September 23, 2014 9:00 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Initial focus on search field?

I will offer a dissenting viewpoint.

There is nothing inherently inaccessible about setting the focus to a
specific field on a page.

It isn't a problem for screen reader users because screen readers don't even
always start reading from the top of the page when focus isn't set to a
field. I also think that, if a screen reader has spent much time on the
web, they won't think a search field or any other field is likely to be the
first item on the page.

It sounds like the problem for keyboard users is not so much setting focus
to a field as much as it is ensuring a keyboard user knows where the focus
is.

Certainly, it sounds like setting focus to a specific field might sometimes
cause additional annoyance to keyboard users, but I'm not sure that is the
same as being an accessibility issue. That sounds more like a usability
issue. However, at the same time, it sounds like the reason for setting
focus to a field is in order to make the user interface more usable.

I would actually tell the developer not to do any special kind of coding.
Just set focus to the field and don't hide any focus indicators.

Thanks!
Tim


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Monday, September 22, 2014 2:35 PM
To: WebAIM Discussion List
Subject: [WebAIM] Initial focus on search field?

Hello, all.

Do you have a sense for what is best practice concerning where focus should
initially be set on pages in complex web sites that contain a prominent
global search field on every page?

For our site, the search field appears after an initial set of navigation
links, and at this point, changing the order of the menu links and the
search field in the code isn't feasible. An original design constraint was
that the search field be automatically given focus upon page load, since
usability studies showed that most people preferred using search to navigate
the site.

However, I was concerned that this could present problems for screen reader
users who might not notice the list of links before the search field. This
does seem to be a common pattern on the web though, so I wonder if screen
reader users would expect (and perhaps prefer) this behavior.

Initially though, I recommended against explicitly setting focus.
Instead, I suggested best practice would be to add, at the start of the
page, a single skip link to the main content, and to create landmark regions
for the main page areas (including role="search" for the where the search
field appears). Screen reader users could then use landmark navigation to
quickly get to the search field.

The developer has gotten pushback though, because of the original design
requirement mandating that focus be set to the initial search field. He has
tried to be creative by not initially setting focus, instead making it so
that, as soon as the user begins typing, focus is set to the search field.
So a tab takes the user to the first link in the menu on the page, but
typing "a search string" automatically moves the user to the search field
and enters the text typed into the field.
This is problematic, though, because some keys are reserved as page
navigation commands by some screen readers, such that typing "b" takes you
to the first button on the page, etc.

At this point, given the constraints we're operating under, I'm leaning
towards just telling him to set focus to the search field, with the thought
that screen reader users may expect this sort of thing and figure things
out, especially given the landmarks provided.
What do you think?

Thanks,
Rob

--
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
messages to = EMAIL ADDRESS REMOVED =
messages to = EMAIL ADDRESS REMOVED =

From: Liko, Todd
Date: Tue, Sep 23 2014 9:01AM
Subject: Re: Initial focus on search field?
← Previous message | Next message →

Hi all.

Very good read on this subject. I understand the idea behind making a website more usable/more convenient.

For me, it is about expected behavior and choosing how I want to navigate the website, whether do so by keyboard or using a mouse. When visiting a site, I am not expecting the focus to be somewhere within the page. I do not want someone making the decision for me where I should start tabbing.

One example is when I am completing a form requesting a phone number. It is split into three fields. Sometimes, I must tab to the next field, sometime the focus automatically moves to the next field upon completion of the previous field. Some people like the convenience, I do not.

Todd.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michael Bullis, Executive Director, The IMAGE Center of Maryland
Sent: Tuesday, September 23, 2014 9:25 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] Initial focus on search field?

As a user and not a developer, I too think it's a usability issue. If the way you want visual people to use the site is by starting them at the searchbox, then do it for nonvisual users as well. Google, back in earlier iterations, use to set the focus to the searchbox automatically. I found it very helpful, since that's where I wanted to go mostly.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tim Harshbarger
Sent: Tuesday, September 23, 2014 9:00 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Initial focus on search field?

I will offer a dissenting viewpoint.

There is nothing inherently inaccessible about setting the focus to a specific field on a page.

It isn't a problem for screen reader users because screen readers don't even always start reading from the top of the page when focus isn't set to a field. I also think that, if a screen reader has spent much time on the web, they won't think a search field or any other field is likely to be the first item on the page.

It sounds like the problem for keyboard users is not so much setting focus to a field as much as it is ensuring a keyboard user knows where the focus is.

Certainly, it sounds like setting focus to a specific field might sometimes cause additional annoyance to keyboard users, but I'm not sure that is the same as being an accessibility issue. That sounds more like a usability issue. However, at the same time, it sounds like the reason for setting focus to a field is in order to make the user interface more usable.

I would actually tell the developer not to do any special kind of coding.
Just set focus to the field and don't hide any focus indicators.

Thanks!
Tim


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Monday, September 22, 2014 2:35 PM
To: WebAIM Discussion List
Subject: [WebAIM] Initial focus on search field?

Hello, all.

Do you have a sense for what is best practice concerning where focus should initially be set on pages in complex web sites that contain a prominent global search field on every page?

For our site, the search field appears after an initial set of navigation links, and at this point, changing the order of the menu links and the search field in the code isn't feasible. An original design constraint was that the search field be automatically given focus upon page load, since usability studies showed that most people preferred using search to navigate the site.

However, I was concerned that this could present problems for screen reader users who might not notice the list of links before the search field. This does seem to be a common pattern on the web though, so I wonder if screen reader users would expect (and perhaps prefer) this behavior.

Initially though, I recommended against explicitly setting focus.
Instead, I suggested best practice would be to add, at the start of the page, a single skip link to the main content, and to create landmark regions for the main page areas (including role="search" for the where the search field appears). Screen reader users could then use landmark navigation to quickly get to the search field.

The developer has gotten pushback though, because of the original design requirement mandating that focus be set to the initial search field. He has tried to be creative by not initially setting focus, instead making it so that, as soon as the user begins typing, focus is set to the search field.
So a tab takes the user to the first link in the menu on the page, but typing "a search string" automatically moves the user to the search field and enters the text typed into the field.
This is problematic, though, because some keys are reserved as page navigation commands by some screen readers, such that typing "b" takes you to the first button on the page, etc.

At this point, given the constraints we're operating under, I'm leaning towards just telling him to set focus to the search field, with the thought that screen reader users may expect this sort of thing and figure things out, especially given the landmarks provided.
What do you think?

Thanks,
Rob

--
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: Robert Fentress
Date: Mon, Sep 29 2014 9:21AM
Subject: Re: Initial focus on search field?
← Previous message | No next message

How about changing tabindex so the search field is the second thing focus
is brought to when the tab key is pressed (after the skip link)? This may
make things easier for those keyboard-preferring users who want to quickly
get to the search field. The problem is that this is not the order things
appear in the page visually, since the first row of navigation links
appears above the search field. Even though the search field is very close
to the upper-right corner of the page, it seems bad to violate user's
expectations by having the focus move backward in the visual flow. . . so
that's probably out as a solution.

Folks here have raised the issue that the autofocus is bad for
keyboard-preferring users, but that seems counterintuitive to me. I am a
keyboard-preferring user myself, and I'd rather my focus be placed in that
field, because the links that precede it aren't ones I'd usually follow.
My understanding is that the requirement for focus to be placed in the
search field originally was based on specific usability testing for this
site, rather than general research. If we don't autofocus, that means a
keyboard-preferring user has to hit tab 13 times to get to the search
field, which research suggests is usually his/her preferred destination.

There are always many conflicting requirements in a page design--aesthetic,
political, usability preferences of different classes of visitors--and
there is often a certain thrownness to things, as Heidegger would say,
where we don't get to start from scratch, but have to work within existing
constraints. Certainly makes things interesting.

Thanks for the feedback. So is the consensus here that the autofocus
should just be removed altogether? Any creative solutions out there to
this conundrum, given that a major page redesign, where the
order/positioning of elements on the page is changed, is not in the offing?

Best,
Rob

On Tue, Sep 23, 2014 at 11:01 AM, Liko, Todd < = EMAIL ADDRESS REMOVED = > wrote:

> Hi all.
>
> Very good read on this subject. I understand the idea behind making a
> website more usable/more convenient.
>
> For me, it is about expected behavior and choosing how I want to navigate
> the website, whether do so by keyboard or using a mouse. When visiting a
> site, I am not expecting the focus to be somewhere within the page. I do
> not want someone making the decision for me where I should start tabbing.
>
> One example is when I am completing a form requesting a phone number. It
> is split into three fields. Sometimes, I must tab to the next field,
> sometime the focus automatically moves to the next field upon completion of
> the previous field. Some people like the convenience, I do not.
>
> Todd.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Michael Bullis,
> Executive Director, The IMAGE Center of Maryland
> Sent: Tuesday, September 23, 2014 9:25 AM
> To: 'WebAIM Discussion List'
> Subject: Re: [WebAIM] Initial focus on search field?
>
> As a user and not a developer, I too think it's a usability issue. If the
> way you want visual people to use the site is by starting them at the
> searchbox, then do it for nonvisual users as well. Google, back in earlier
> iterations, use to set the focus to the searchbox automatically. I found
> it very helpful, since that's where I wanted to go mostly.
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tim Harshbarger
> Sent: Tuesday, September 23, 2014 9:00 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Initial focus on search field?
>
> I will offer a dissenting viewpoint.
>
> There is nothing inherently inaccessible about setting the focus to a
> specific field on a page.
>
> It isn't a problem for screen reader users because screen readers don't
> even always start reading from the top of the page when focus isn't set to
> a field. I also think that, if a screen reader has spent much time on the
> web, they won't think a search field or any other field is likely to be the
> first item on the page.
>
> It sounds like the problem for keyboard users is not so much setting focus
> to a field as much as it is ensuring a keyboard user knows where the focus
> is.
>
> Certainly, it sounds like setting focus to a specific field might
> sometimes cause additional annoyance to keyboard users, but I'm not sure
> that is the same as being an accessibility issue. That sounds more like a
> usability issue. However, at the same time, it sounds like the reason for
> setting focus to a field is in order to make the user interface more usable.
>
> I would actually tell the developer not to do any special kind of coding.
> Just set focus to the field and don't hide any focus indicators.
>
> Thanks!
> Tim
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
> Sent: Monday, September 22, 2014 2:35 PM
> To: WebAIM Discussion List
> Subject: [WebAIM] Initial focus on search field?
>
> Hello, all.
>
> Do you have a sense for what is best practice concerning where focus
> should initially be set on pages in complex web sites that contain a
> prominent global search field on every page?
>
> For our site, the search field appears after an initial set of navigation
> links, and at this point, changing the order of the menu links and the
> search field in the code isn't feasible. An original design constraint was
> that the search field be automatically given focus upon page load, since
> usability studies showed that most people preferred using search to
> navigate the site.
>
> However, I was concerned that this could present problems for screen
> reader users who might not notice the list of links before the search
> field. This does seem to be a common pattern on the web though, so I
> wonder if screen reader users would expect (and perhaps prefer) this
> behavior.
>
> Initially though, I recommended against explicitly setting focus.
> Instead, I suggested best practice would be to add, at the start of the
> page, a single skip link to the main content, and to create landmark
> regions for the main page areas (including role="search" for the where the
> search field appears). Screen reader users could then use landmark
> navigation to quickly get to the search field.
>
> The developer has gotten pushback though, because of the original design
> requirement mandating that focus be set to the initial search field. He
> has tried to be creative by not initially setting focus, instead making it
> so that, as soon as the user begins typing, focus is set to the search
> field.
> So a tab takes the user to the first link in the menu on the page, but
> typing "a search string" automatically moves the user to the search field
> and enters the text typed into the field.
> This is problematic, though, because some keys are reserved as page
> navigation commands by some screen readers, such that typing "b" takes you
> to the first button on the page, etc.
>
> At this point, given the constraints we're operating under, I'm leaning
> towards just telling him to set focus to the search field, with the thought
> that screen reader users may expect this sort of thing and figure things
> out, especially given the landmarks provided.
> What do you think?
>
> Thanks,
> Rob
>
> --
> 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
> > > messages to = EMAIL ADDRESS REMOVED =
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > >



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