RE: Auto-Tabbing - Is this ever allowed?

We should be campaigning browser vendors to introduce better keyboard 
navigation support 

I agree.

Making assumptions about the way someone wants to navigate content is 
generally not a good thing.

I agree.

So, where should the default keyboard be placed then?  at the top of the 
page?  Isn't that also making an assumption that forces everyone to start 
at the top? 
I agree that starting at the top to "read the information" is valid. 
Sighted users can scan the page, screen reader users can scan the page, 
and magnifier users can scan the page - all without moving the keyboard 
focus.  But when someone wants to simple einter a search term, or simple 
enter the userID (or perhaps better yet the password because the user-ID 
is already entered saved if that is your preference), is seems more 
effeieicnt to have the keyboard focus placed where it will be most often 
used.  It would be really cool to have keyboard focus be user 
configurable, but I do not know of technology to do that. 

It seems abitrary to me for keyboard focus default placement to be placed 
at the top of the page and not on the "best" interactive spot on the page 
- but as far as I know, today the developer has to pick one as the 
default.  Same with dialogs that have 3 choices (Yes, Cancel, etc.) - one 
of them is picked to be the default choice.  maybe I'm old school where 
widgets developed for Windows all and predicable behavior.  Similar to 
what many call today the "pattern libray" for an app, widget ;library, or 
suite of web apps - but fundamentally that has to be a starting point, and 
I choose to place the keyboard focus on the most efficient place to 
complete the task of the page (which would rarely be the top of the page I 
would think).. 

I thought there was some initial consensus with using the Google home page 
and the Log-in page example that the keyboard focus placement in the entry 
field was best practice. Are you suggesting the keyboard focus be placed 
somewhere else?  Where?

____________________________________________
Regards,
Phill Jenkins, 
IBM Accessibility



From:   Léonie Watson <lwatson@paciellogroup.com>
To:     Phill Jenkins/Austin/IBM@IBMUS, "'Jim Allan'" <jimallan@tsbvi.edu>
Cc:     "'WAI-IG'" <w3c-wai-ig@w3.org>
Date:   05/28/2015 04:40 PM
Subject:        RE: Auto-Tabbing - Is this ever allowed?



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 order.
 
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 behalf.
 
Léonie.
 
-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com