WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Initial focus on search field?


From: Robert Fentress
Date: Sep 22, 2014 2:15PM

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?


On Mon, Sep 22, 2014 at 3:43 PM, < <EMAIL 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

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