- 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