WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Initial focus on search field?

for

From: Mallory van Achterberg
Date: Sep 23, 2014 4:20AM

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/