E-mail List Archives
Thread: Re: form "auto tab"
Number of posts in this thread: 8 (In chronological order)
From: Paul Adam
Date: Wed, Nov 09 2011 12:54PM
Subject: Re: form "auto tab"
No previous message | Next message →
I also find the auto-advancing form fields annoying and recommend avoiding
it. I can't find the exact location in WCAG but I thought it recommended
that if you use this sort of feature to warn the users before hand. Makes
sense to me. I often end up hitting the TAB button and wind up 2 form
fields ahead and have to go back to correct my mistakes.
On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage < = EMAIL ADDRESS REMOVED = > wrote:
> hi All,
>
> I'd like to get input on the use of "auto tab" in form field navigation. I
> generally feel it is a poor practice, but would like to know the general
> consensus on its use.
>
> Thanks,
>
> Jon
>
>
From: Ryan Hemphill
Date: Wed, Nov 09 2011 1:00PM
Subject: Re: form "auto tab"
← Previous message | Next message →
The skipping of form fields is probably happening because the tab key event
is getting passed to the focus target. It's easy enough to avoid by a
event.preventDefault() et al of bubbling. Here's my little catchall which
seems to knock out pretty much everything..
function preventEvents(event)
{
/* NOTE: insures that keyup event doesn't fire on target as well. */
event.preventDefault();
event.stopPropagation();
event.stopImmediatePropagation(); /* you may not want this one, depending
on your situation, so comment it out if things are not in a happy place */
}
That being said, I still hate the idea of auto-tab. I don't blame anyone
who ends up complaining about it's use either. They aren't whining - it
really is annoying and a bad idea.
On Wed, Nov 9, 2011 at 2:51 PM, Paul Adam < = EMAIL ADDRESS REMOVED = > wrote:
> I also find the auto-advancing form fields annoying and recommend avoiding
> it. I can't find the exact location in WCAG but I thought it recommended
> that if you use this sort of feature to warn the users before hand. Makes
> sense to me. I often end up hitting the TAB button and wind up 2 form
> fields ahead and have to go back to correct my mistakes.
>
> On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > hi All,
> >
> > I'd like to get input on the use of "auto tab" in form field navigation.
> I
> > generally feel it is a poor practice, but would like to know the general
> > consensus on its use.
> >
> > Thanks,
> >
> > Jon
> >
> >
From: Ryan Hemphill
Date: Wed, Nov 09 2011 1:06PM
Subject: Re: form "auto tab"
← Previous message | Next message →
I'm not going to speak for anyone but myself - even as a sighted user I
consider the auto-tab an incredibly bad implementation of focus management.
I can't even imagine what it would be like for a blind user, except that
it would be terrible.
On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage < = EMAIL ADDRESS REMOVED = > wrote:
> hi All,
>
> I'd like to get input on the use of "auto tab" in form field navigation. I
> generally feel it is a poor practice, but would like to know the general
> consensus on its use.
>
> Thanks,
>
> Jon
>
>
From: Bryan Garaventa
Date: Wed, Nov 09 2011 1:30PM
Subject: Re: form "auto tab"
← Previous message | Next message →
Would it be benefitial to add cancelBubble=true to this as well?
----- Original Message -----
From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, November 09, 2011 12:01 PM
Subject: Re: [WebAIM] form "auto tab"
> The skipping of form fields is probably happening because the tab key
> event
> is getting passed to the focus target. It's easy enough to avoid by a
> event.preventDefault() et al of bubbling. Here's my little catchall which
> seems to knock out pretty much everything..
>
> function preventEvents(event)
> {
> /* NOTE: insures that keyup event doesn't fire on target as well. */
> event.preventDefault();
> event.stopPropagation();
> event.stopImmediatePropagation(); /* you may not want this one, depending
> on your situation, so comment it out if things are not in a happy place */
> }
>
> That being said, I still hate the idea of auto-tab. I don't blame anyone
> who ends up complaining about it's use either. They aren't whining - it
> really is annoying and a bad idea.
>
>
>
>
> On Wed, Nov 9, 2011 at 2:51 PM, Paul Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I also find the auto-advancing form fields annoying and recommend
>> avoiding
>> it. I can't find the exact location in WCAG but I thought it recommended
>> that if you use this sort of feature to warn the users before hand. Makes
>> sense to me. I often end up hitting the TAB button and wind up 2 form
>> fields ahead and have to go back to correct my mistakes.
>>
>> On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> > hi All,
>> >
>> > I'd like to get input on the use of "auto tab" in form field
>> > navigation.
>> I
>> > generally feel it is a poor practice, but would like to know the
>> > general
>> > consensus on its use.
>> >
>> > Thanks,
>> >
>> > Jon
>> >
>> >
From: Ryan Hemphill
Date: Wed, Nov 09 2011 1:48PM
Subject: Re: form "auto tab"
← Previous message | Next message →
Having looked into it further, you are correct - but only for IE and only
through 8.
cancelBubble is the IE equivalent of stopPropagation (of course, being MS,
they don't follow the standards, surprise surprise.)
In my case (and some may find this interesting) I am using jQuery and
thanks to myvery well informed fellow dev I found out that jQuery insures
that it works for IE as well without doing the cancelBubble which is why I
haven't had problems.
stopPropagation is supported by IE 9.
On Wed, Nov 9, 2011 at 3:30 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:
> Would it be benefitial to add cancelBubble=true to this as well?
>
>
> ----- Original Message -----
> From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Wednesday, November 09, 2011 12:01 PM
> Subject: Re: [WebAIM] form "auto tab"
>
>
> > The skipping of form fields is probably happening because the tab key
> > event
> > is getting passed to the focus target. It's easy enough to avoid by a
> > event.preventDefault() et al of bubbling. Here's my little catchall
> which
> > seems to knock out pretty much everything..
> >
> > function preventEvents(event)
> > {
> > /* NOTE: insures that keyup event doesn't fire on target as well. */
> > event.preventDefault();
> > event.stopPropagation();
> > event.stopImmediatePropagation(); /* you may not want this one,
> depending
> > on your situation, so comment it out if things are not in a happy place
> */
> > }
> >
> > That being said, I still hate the idea of auto-tab. I don't blame anyone
> > who ends up complaining about it's use either. They aren't whining - it
> > really is annoying and a bad idea.
> >
> >
> >
> >
> > On Wed, Nov 9, 2011 at 2:51 PM, Paul Adam < = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> I also find the auto-advancing form fields annoying and recommend
> >> avoiding
> >> it. I can't find the exact location in WCAG but I thought it recommended
> >> that if you use this sort of feature to warn the users before hand.
> Makes
> >> sense to me. I often end up hitting the TAB button and wind up 2 form
> >> fields ahead and have to go back to correct my mistakes.
> >>
> >> On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage < = EMAIL ADDRESS REMOVED = >
> >> wrote:
> >>
> >> > hi All,
> >> >
> >> > I'd like to get input on the use of "auto tab" in form field
> >> > navigation.
> >> I
> >> > generally feel it is a poor practice, but would like to know the
> >> > general
> >> > consensus on its use.
> >> >
> >> > Thanks,
> >> >
> >> > Jon
> >> >
> >> >
From: Kevin Chao
Date: Wed, Nov 09 2011 3:36PM
Subject: Re: form "auto tab"
← Previous message | Next message →
Auto-tab from a screen reader/keyboard user point is absolutely awful,
annoying, and I think should never be used.
Kevin
On 11/9/11, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
> Having looked into it further, you are correct - but only for IE and only
> through 8.
>
> cancelBubble is the IE equivalent of stopPropagation (of course, being MS,
> they don't follow the standards, surprise surprise.)
>
> In my case (and some may find this interesting) I am using jQuery and
> thanks to myvery well informed fellow dev I found out that jQuery insures
> that it works for IE as well without doing the cancelBubble which is why I
> haven't had problems.
>
> stopPropagation is supported by IE 9.
>
> On Wed, Nov 9, 2011 at 3:30 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Would it be benefitial to add cancelBubble=true to this as well?
>>
>>
>> ----- Original Message -----
>> From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>> Sent: Wednesday, November 09, 2011 12:01 PM
>> Subject: Re: [WebAIM] form "auto tab"
>>
>>
>> > The skipping of form fields is probably happening because the tab key
>> > event
>> > is getting passed to the focus target. It's easy enough to avoid by a
>> > event.preventDefault() et al of bubbling. Here's my little catchall
>> which
>> > seems to knock out pretty much everything..
>> >
>> > function preventEvents(event)
>> > {
>> > /* NOTE: insures that keyup event doesn't fire on target as well. */
>> > event.preventDefault();
>> > event.stopPropagation();
>> > event.stopImmediatePropagation(); /* you may not want this one,
>> depending
>> > on your situation, so comment it out if things are not in a happy place
>> */
>> > }
>> >
>> > That being said, I still hate the idea of auto-tab. I don't blame
>> > anyone
>> > who ends up complaining about it's use either. They aren't whining - it
>> > really is annoying and a bad idea.
>> >
>> >
>> >
>> >
>> > On Wed, Nov 9, 2011 at 2:51 PM, Paul Adam < = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> >> I also find the auto-advancing form fields annoying and recommend
>> >> avoiding
>> >> it. I can't find the exact location in WCAG but I thought it
>> >> recommended
>> >> that if you use this sort of feature to warn the users before hand.
>> Makes
>> >> sense to me. I often end up hitting the TAB button and wind up 2 form
>> >> fields ahead and have to go back to correct my mistakes.
>> >>
>> >> On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage < = EMAIL ADDRESS REMOVED = >
>> >> wrote:
>> >>
>> >> > hi All,
>> >> >
>> >> > I'd like to get input on the use of "auto tab" in form field
>> >> > navigation.
>> >> I
>> >> > generally feel it is a poor practice, but would like to know the
>> >> > general
>> >> > consensus on its use.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Jon
>> >> >
>> >> >
From: SaravanaMoorthy.P@cognizant.com
Date: Thu, Nov 10 2011 8:39AM
Subject: Re: form "auto tab"
← Previous message | Next message →
Guys,
Usability professionals think that they are very smart and thought of
including this feature, so that the users can avoid couple of
clicks/tabbing.
However they don't think how this feature will lead a accessibility
barrier for non-visual users.
Even I found this "Irritating Auto Tabbing" thing when I was doing a
credit card transaction where it requires the card number in 4 sets(each
4 no.) of text fields.
As a sighted user, I managed to enter the card number. But non-visual
users will struggle a lot.
My Thought - Developers can provide a check box with a label associated
to it stating "Disable Auto Tabbing" (before the text fields).
Doing so, this could be usable and also break the accessibility barrier.
Comments, Thoughts, Suggestion...?
cheers,
Saran
-----Original Message-----
From: Kevin Chao [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, November 10, 2011 4:04 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] form "auto tab"
Auto-tab from a screen reader/keyboard user point is absolutely awful,
annoying, and I think should never be used.
Kevin
On 11/9/11, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
> Having looked into it further, you are correct - but only for IE and
only
> through 8.
>
> cancelBubble is the IE equivalent of stopPropagation (of course, being
MS,
> they don't follow the standards, surprise surprise.)
>
> In my case (and some may find this interesting) I am using jQuery and
> thanks to myvery well informed fellow dev I found out that jQuery
insures
> that it works for IE as well without doing the cancelBubble which is
why I
> haven't had problems.
>
> stopPropagation is supported by IE 9.
>
> On Wed, Nov 9, 2011 at 3:30 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Would it be benefitial to add cancelBubble=true to this as well?
>>
>>
>> ----- Original Message -----
>> From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>> Sent: Wednesday, November 09, 2011 12:01 PM
>> Subject: Re: [WebAIM] form "auto tab"
>>
>>
>> > The skipping of form fields is probably happening because the tab
key
>> > event
>> > is getting passed to the focus target. It's easy enough to avoid
by a
>> > event.preventDefault() et al of bubbling. Here's my little
catchall
>> which
>> > seems to knock out pretty much everything..
>> >
>> > function preventEvents(event)
>> > {
>> > /* NOTE: insures that keyup event doesn't fire on target as well.
*/
>> > event.preventDefault();
>> > event.stopPropagation();
>> > event.stopImmediatePropagation(); /* you may not want this one,
>> depending
>> > on your situation, so comment it out if things are not in a happy
place
>> */
>> > }
>> >
>> > That being said, I still hate the idea of auto-tab. I don't blame
>> > anyone
>> > who ends up complaining about it's use either. They aren't whining
- it
>> > really is annoying and a bad idea.
>> >
>> >
>> >
>> >
>> > On Wed, Nov 9, 2011 at 2:51 PM, Paul Adam < = EMAIL ADDRESS REMOVED = >
wrote:
>> >
>> >> I also find the auto-advancing form fields annoying and recommend
>> >> avoiding
>> >> it. I can't find the exact location in WCAG but I thought it
>> >> recommended
>> >> that if you use this sort of feature to warn the users before
hand.
>> Makes
>> >> sense to me. I often end up hitting the TAB button and wind up 2
form
>> >> fields ahead and have to go back to correct my mistakes.
>> >>
>> >> On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage
< = EMAIL ADDRESS REMOVED = >
>> >> wrote:
>> >>
>> >> > hi All,
>> >> >
>> >> > I'd like to get input on the use of "auto tab" in form field
>> >> > navigation.
>> >> I
>> >> > generally feel it is a poor practice, but would like to know the
>> >> > general
>> >> > consensus on its use.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Jon
>> >> >
>> >> >
From: Birkir R. Gunnarsson
Date: Thu, Nov 10 2011 8:51AM
Subject: Re: form "auto tab"
← Previous message | No next message
As a screen reader user, I have no issues with the auto tab features
if -- and this is an important if -- I am expecting it.
Problems come up as soon as I do press tab to get to the next field,
but auto tab has already sent me there, so I jump to the wrong field,
and chaos ensues.
I find it quite convenient to, for instance, enter phone numbers into
these kind of fields, that way I don't have to worry about where to
put the dashes, or whether to type phone number without dashes etc (of
course this could be done just as well without the auto tab feature).
Basically, I find it somewhat convenient, and not necessarily a
barrier, if I expect it, and I think people need to have the choice to
turn this off.
Assistive Technology, perhaps, should have a feature to block these,
or handle them differently, like screen readers do for onSelect/jump
menus, that is one possible solution.
On 11/10/11, = EMAIL ADDRESS REMOVED =
< = EMAIL ADDRESS REMOVED = > wrote:
> Guys,
>
> Usability professionals think that they are very smart and thought of
> including this feature, so that the users can avoid couple of
> clicks/tabbing.
> However they don't think how this feature will lead a accessibility
> barrier for non-visual users.
>
> Even I found this "Irritating Auto Tabbing" thing when I was doing a
> credit card transaction where it requires the card number in 4 sets(each
> 4 no.) of text fields.
> As a sighted user, I managed to enter the card number. But non-visual
> users will struggle a lot.
>
> My Thought - Developers can provide a check box with a label associated
> to it stating "Disable Auto Tabbing" (before the text fields).
> Doing so, this could be usable and also break the accessibility barrier.
>
> Comments, Thoughts, Suggestion...?
>
>
> cheers,
> Saran
>
>
> -----Original Message-----
> From: Kevin Chao [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, November 10, 2011 4:04 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] form "auto tab"
>
> Auto-tab from a screen reader/keyboard user point is absolutely awful,
> annoying, and I think should never be used.
>
> Kevin
>
> On 11/9/11, Ryan Hemphill < = EMAIL ADDRESS REMOVED = > wrote:
>> Having looked into it further, you are correct - but only for IE and
> only
>> through 8.
>>
>> cancelBubble is the IE equivalent of stopPropagation (of course, being
> MS,
>> they don't follow the standards, surprise surprise.)
>>
>> In my case (and some may find this interesting) I am using jQuery and
>> thanks to myvery well informed fellow dev I found out that jQuery
> insures
>> that it works for IE as well without doing the cancelBubble which is
> why I
>> haven't had problems.
>>
>> stopPropagation is supported by IE 9.
>>
>> On Wed, Nov 9, 2011 at 3:30 PM, Bryan Garaventa <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> Would it be benefitial to add cancelBubble=true to this as well?
>>>
>>>
>>> ----- Original Message -----
>>> From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
>>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>>> Sent: Wednesday, November 09, 2011 12:01 PM
>>> Subject: Re: [WebAIM] form "auto tab"
>>>
>>>
>>> > The skipping of form fields is probably happening because the tab
> key
>>> > event
>>> > is getting passed to the focus target. It's easy enough to avoid
> by a
>>> > event.preventDefault() et al of bubbling. Here's my little
> catchall
>>> which
>>> > seems to knock out pretty much everything..
>>> >
>>> > function preventEvents(event)
>>> > {
>>> > /* NOTE: insures that keyup event doesn't fire on target as well.
> */
>>> > event.preventDefault();
>>> > event.stopPropagation();
>>> > event.stopImmediatePropagation(); /* you may not want this one,
>>> depending
>>> > on your situation, so comment it out if things are not in a happy
> place
>>> */
>>> > }
>>> >
>>> > That being said, I still hate the idea of auto-tab. I don't blame
>>> > anyone
>>> > who ends up complaining about it's use either. They aren't whining
> - it
>>> > really is annoying and a bad idea.
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Nov 9, 2011 at 2:51 PM, Paul Adam < = EMAIL ADDRESS REMOVED = >
> wrote:
>>> >
>>> >> I also find the auto-advancing form fields annoying and recommend
>>> >> avoiding
>>> >> it. I can't find the exact location in WCAG but I thought it
>>> >> recommended
>>> >> that if you use this sort of feature to warn the users before
> hand.
>>> Makes
>>> >> sense to me. I often end up hitting the TAB button and wind up 2
> form
>>> >> fields ahead and have to go back to correct my mistakes.
>>> >>
>>> >> On Wed, Nov 9, 2011 at 2:35 PM, Jon Brundage
> < = EMAIL ADDRESS REMOVED = >
>>> >> wrote:
>>> >>
>>> >> > hi All,
>>> >> >
>>> >> > I'd like to get input on the use of "auto tab" in form field
>>> >> > navigation.
>>> >> I
>>> >> > generally feel it is a poor practice, but would like to know the
>>> >> > general
>>> >> > consensus on its use.
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > Jon
>>> >> >
>>> >> >