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

Re: Auto-Tabbing - Is this ever allowed?

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Thu, 28 May 2015 14:57:40 -0500
To: Jim Allan <jimallan@tsbvi.edu>
Cc: WAI-IG <w3c-wai-ig@w3.org>
Message-ID: <OFA37FE0B9.2B2557DE-ON86257E53.006B2188-86257E53.006DA70D@us.ibm.com>
I agree with you, because your example doesn't include the "enter" key 
that I mentioned.  If that is what you describe as "auto-tabbing" then I 
agree.  My definition included a step to enter the input.  Your scenario 
of a user simply entering 3 digits and then the app auto-moves the focus 
is a problem for everyone! 

My scenario was simply trying to remove the need for additional 
keypresses, so if the tab key,  instead of enter, is the preferred way to 
move the focus when the user's input is complete, then we also agree. 

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. 
____________________________________________
Regards,
Phill Jenkins, 
IBM Accessibility




From:   Jim Allan <jimallan@tsbvi.edu>
To:     Phill Jenkins/Austin/IBM@IBMUS
Cc:     WAI-IG <w3c-wai-ig@w3.org>
Date:   05/28/2015 02:08 PM
Subject:        Re: Auto-Tabbing - Is this ever allowed?



Phill, 
I disagree. 
auto tabbing in my understanding is having a phone number input with 3 
fields. when you type 3 digit in the first field (which is its max size) 
the focus is automatically moved to the next field. The user did nothing 
except type 3 digits. 
I tab through form fields. On a form with autotab, unless I pay close 
attention, I skip fields because I hit tab to move to the next field. 
Autotab breaks my behavior model for interacting with forms. 

Also, If you hit enter in a form, the submit button is generally fired. I 
have seen a few forms where you must explicitly tab into (focus) a submit 
button in order to hit enter on it, but those are very few. 

Jumping to the first field of a form (skipping title, instructions, etc.) 
when entering a page seems like poor usability for screen reader users and 
keyboard users. You enter a page, you are immediately placed in a form, 
when you hit tab you go to the next field. What happened to all the page 
navigation? What if I went to the page because it has other information 
other than the form? Then as a user, I must exit the form, reorient myself 
to the page, and now I can complete my task. That's a hassle. 

Jim

On Thu, May 28, 2015 at 12:27 PM, Phill Jenkins <pjenkins@us.ibm.com> 
wrote:
I would not label this as "auto-tabbing", but simply optimized keyboard 
navigation.  We all want a better user experience.   

Example scenario: so placing the input focus in an input field when the 
page loads is a best practice because all users can simply begin typing 
and the input filed will receive the keystrokes, no extra tabbing or arrow 
keys needed, or gestures required = better user experience.  If the a user 
wants the label to be spoken as well, then that is an AT setting or 
configuration since WCAG already has the provision for associating the 
label with the input field.  After the user types the input and then 
presses enter (or SpaceBar) it would also be a best practice for the web 
page/app to move the input focus to the next input element in the form.  
Note that I do not consider that auto-tabbing since the focus only moves 
after the user presses enter to complete the input step.   

What some call auto-scanning, as is typical for AT the allows 
auto-scanning of on screen keyboards is useful for some, but not all user 
with disabilities.  So  auto-scanning should be user or AT configurable.  
I would rarely (never?) recommend that the web app developer provide the 
auto-scanning since it could (would?) conflict with the platform or more 
commonly, the user's AT settings. 

____________________________________________
Regards,
Phill Jenkins, 
IBM Accessibility



From:        Léonie Watson <lwatson@paciellogroup.com> 
To:        "'Wishnew, Mary '" <mary.wishnew@citi.com>, "'IG - WAI Interest 
Group List list'" <w3c-wai-ig@w3.org> 
Date:        05/28/2015 11:26 AM 
Subject:        RE: Auto-Tabbing - Is this ever allowed? 




-----Original Message-----
From: Wishnew, Mary [mailto:mary.wishnew@citi.com] 
Sent: 28 May 2015 16:41

I have worked in the past with a reputable Third Party Accessibility 
Vendor that has advised auto-tabbing should never be allowed for a form 
with input fields such as an online application.  The application would 
have multiple input fields such as First Name, Last Name, Address, phone 
number, SSN, etc.  I realize that if the user isn't advised the form will 
auto tab they can end up multiple fields down the form instead of moving 
to the next field as they don't realize the form has auto-tabbed.  

<SNIPPED>

The development team wants to add auto-tabbing back into the application 
form.  What is the industry best practice?  I would like to get input from 
those on the list about auto-tabbing. I am receiving significant push back 
to add this tabbing back into the form and would like to advise 
accurately.

Speaking as a screen reader/keyboard user, I strongly dislike having 
auto-tab functionality imposed on me. It is unexpected, and based on a 
flawed assumption that it is helpful.

It's worth noting that it takes me more time and effort to correct 
mistakes caused by auto-tab, than it does to move focus for myself. 

Léonie.

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com








-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 28 May 2015 19:58:16 UTC

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