W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2015

RE: Auto-Tabbing - Is this ever allowed?

From: Léonie Watson <lwatson@paciellogroup.com>
Date: Thu, 28 May 2015 22:40:05 +0100
To: "'Phill Jenkins'" <pjenkins@us.ibm.com>, "'Jim Allan'" <jimallan@tsbvi.edu>
Cc: "'WAI-IG'" <w3c-wai-ig@w3.org>
Message-ID: <005501d0998e$dd2e7700$978b6500$@paciellogroup.com>
From: Phill Jenkins [mailto:pjenkins@us.ibm.com] 
Sent: 28 May 2015 20:58

However, regarding the default focus being placed in the entry field, I
think we need to separate learning and exploring a page from efficiently
operating it.  For example.  do you seriously want me to have to tab to the
user-ID entry field of a log-in page, or wouldn't you agree that the
keyboard input focus should be placed by default into user-ID field?
Designing a page or form for efficient keyboard input and navigation is the
goal, especially if it is frequently used vs a scenario where the user is
learning and orienting themselves to use the app/page for the first time.
And, remember too that keyboard focus is not the same as the point of regard
where the screen reader reading cursor might be reading.  If there is "other
information other than the form", then I do not think you're talking about
moving the keyboard focus to read that information, but I agree navigation
links and buttons would still need to be in the logical tab order.  There
are also other standard keys for jumping to the bottom of the page, or to
the top.  I still remember the early days of wanna-be developers redundantly
adding a "skip to bottom of page" skip nav link.   I understand that JAWS
and some screen readers have separate "forms mode", but most are getting
better at understanding where the keyboard focus is at and where to place
the reading focus, and which mode to be in when.   


Given that most screen readers automatically switch into forms mode (or the
equivalent) when focus moves to a field, then the screen reader starting
point becomes that field. It is very likely therefore that a screen reader
user would be oblivious to any content prior to the field in the source


Making assumptions about the way someone wants to navigate content is
generally not a good thing. Even when the use case seems strong, that’s not
always (or even often) the case.


For example, Google takes focus to the search field on the assumption people
want to search. Yet many people have Google as their homepage, and use it as
a springboard to access all their other Google services. People like me use
a different search engine entirely (Yandex in case you’re curious), and only
visit Google in order to access other services. In both cases the assumption
about what someone intends to do is flawed.


We should be campaigning browser vendors to introduce better keyboard
navigation support (mirroring the navigation capabilities of screen readers
for example), rather than suggesting developers make assumptions on our





Léonie Watson - Senior accessibility engineer

@LeonieWatson @PacielloGroup PacielloGroup.com



Received on Thursday, 28 May 2015 21:40:26 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 25 May 2017 01:54:15 UTC