E-mail List Archives
Thread: Partial Tabindex Behavior
Number of posts in this thread: 7 (In chronological order)
From: James Bailey
Date: Fri, Jul 18 2014 11:46AM
Subject: Partial Tabindex Behavior
No previous message | Next message →
Hello All,
I evaluated a page and the code contained focusable elements, some with Tabindex set to values > 0 and some without. It seems that elements with a Tabindex are ordered before elements with no Tabindex. Is that correct?
Thanks,
James
James Bailey M.S.
Associate Director
Accessible Education Center
University of Oregon
From: Jukka K. Korpela
Date: Fri, Jul 18 2014 12:20PM
Subject: Re: Partial Tabindex Behavior
← Previous message | Next message →
2014-07-18 20:46, James Bailey wrote:
> I evaluated a page and the code contained focusable elements, some
> with Tabindex set to values > 0 and some without. It seems that
> elements with a Tabindex are ordered before elements with no
> Tabindex. Is that correct?
That's what happens in practice. The specs are somewhat obscure. HTML
4.01 does not explicitly say this:
http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex
But it might be read so that when the tabindex attribute is not present,
it is defaulted to 0 (though this is not stated explicitly in the spec),
and thus such elements fall into category 2 (elements that do not
support tabindex or have it set to 0), which is navigated, in textual
order, after elements with a positive tabindex.
HTML5 is obscure in this issue, too:
http://www.w3.org/TR/html5/editing.html#focus-management
It can be argued that it is safer to assign tabindex to all focusable
elements if it is used at all. But this would just avoid the theoretical
ambiguity, so it's not important in practice.
Yucca
From: David Ashleydale
Date: Fri, Jul 18 2014 1:33PM
Subject: Re: Partial Tabindex Behavior
← Previous message | Next message →
Yes, you can think of elements with no tabindex attribute as having
tabindex="infinite".
So if there are some elements on the page with tabindex set, the focus will
go through all of those first, in numerical order. If two or more items
have the same value, focus goes through them in source code order. After
focus goes to each of those, focus will then go to the first item on the
page in source code order that has no tabindex. And it will go to the
remaining items in source code order.
This is why I usually recommend that if tabindex is used on a page (which
should actually be avoided), you should give everything on the page a
tabindex. Although that's a nightmare to maintain.
David
On Friday, July 18, 2014, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:
> 2014-07-18 20:46, James Bailey wrote:
>
> I evaluated a page and the code contained focusable elements, some
>> with Tabindex set to values > 0 and some without. It seems that
>> elements with a Tabindex are ordered before elements with no
>> Tabindex. Is that correct?
>>
>
> That's what happens in practice. The specs are somewhat obscure. HTML 4.01
> does not explicitly say this:
> http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex
> But it might be read so that when the tabindex attribute is not present,
> it is defaulted to 0 (though this is not stated explicitly in the spec),
> and thus such elements fall into category 2 (elements that do not support
> tabindex or have it set to 0), which is navigated, in textual order, after
> elements with a positive tabindex.
>
> HTML5 is obscure in this issue, too:
> http://www.w3.org/TR/html5/editing.html#focus-management
>
> It can be argued that it is safer to assign tabindex to all focusable
> elements if it is used at all. But this would just avoid the theoretical
> ambiguity, so it's not important in practice.
>
> Yucca
>
> > > >
From: Birkir R. Gunnarsson
Date: Sat, Jul 19 2014 12:51PM
Subject: Re: Partial Tabindex Behavior
← Previous message | Next message →
This is correct, but note that in some browsers shift-tabbing and
tabbing through elements with positive tabindexies gives inconsistent
results (at least I ahve seen tht with screen readers).
Whenever you see positive tabindex being used, I would recommend
calling that out as a potential user issue and recommend that it be
avoided at all cost.
tabindex-'-1' for use with Javascript or on non-focusable anchors that
are targets of skip links is fine, tabindex="0" on elements that are
made up of divs, spans or other non-focusable elements (along with
sufficient keyboard interaction and aria role mapping) is acceptable,
when necessary,
but I have never seen a convincing argument for using positive tabindex values.
It means the source code order is messed up, it causes maintenance
head aches and you risk confusing the users and having inconsistent
keyboard interactions.
I like what the Goodwitch has to say on it (though WebAIM, of course,
has a good overview on this as well, as do many other accessibility
gurus):
http://www.glendathegood.com/blog/?p=604
Cheers
On 7/18/14, David Ashleydale < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, you can think of elements with no tabindex attribute as having
> tabindex="infinite".
> So if there are some elements on the page with tabindex set, the focus will
> go through all of those first, in numerical order. If two or more items
> have the same value, focus goes through them in source code order. After
> focus goes to each of those, focus will then go to the first item on the
> page in source code order that has no tabindex. And it will go to the
> remaining items in source code order.
>
> This is why I usually recommend that if tabindex is used on a page (which
> should actually be avoided), you should give everything on the page a
> tabindex. Although that's a nightmare to maintain.
>
> David
>
> On Friday, July 18, 2014, Jukka K. Korpela < = EMAIL ADDRESS REMOVED = > wrote:
>
>> 2014-07-18 20:46, James Bailey wrote:
>>
>> I evaluated a page and the code contained focusable elements, some
>>> with Tabindex set to values > 0 and some without. It seems that
>>> elements with a Tabindex are ordered before elements with no
>>> Tabindex. Is that correct?
>>>
>>
>> That's what happens in practice. The specs are somewhat obscure. HTML
>> 4.01
>> does not explicitly say this:
>> http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex
>> But it might be read so that when the tabindex attribute is not present,
>> it is defaulted to 0 (though this is not stated explicitly in the spec),
>> and thus such elements fall into category 2 (elements that do not support
>> tabindex or have it set to 0), which is navigated, in textual order,
>> after
>> elements with a positive tabindex.
>>
>> HTML5 is obscure in this issue, too:
>> http://www.w3.org/TR/html5/editing.html#focus-management
>>
>> It can be argued that it is safer to assign tabindex to all focusable
>> elements if it is used at all. But this would just avoid the theoretical
>> ambiguity, so it's not important in practice.
>>
>> Yucca
>>
>> >> >> >>
> > > >
--
Work hard. Have fun. Make history.
From: Patrick H. Lauke
Date: Sat, Jul 19 2014 2:26PM
Subject: Re: Partial Tabindex Behavior
← Previous message | Next message →
On 19/07/2014 19:51, Birkir R. Gunnarsson wrote:
> Whenever you see positive tabindex being used, I would recommend
> calling that out as a potential user issue and recommend that it be
> avoided at all cost.
Tiny sidenote that, from my very cursory testing in iOS/Safari at least,
mobile/tablet browsers ignore tabindex > 0 when you navigate with AT
and/or keyboard...so if tabindex is used to try and force a certain
sensible order due to underlying HTML / source order of focusable
elements being wrong, then note that on these platforms that won't have
the desired effect and the wrong tab cycle will still be there for users.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Whitney Quesenbery
Date: Mon, Jul 21 2014 10:04AM
Subject: Re: Partial Tabindex Behavior
← Previous message | Next message →
Would be unfair to say that TabIndex was a bandaid.
And that it can cause as much harm as good.
And that getting back to good design is a better solution -- in this case,
designing for a logical keyboard sequence.
This seems to me a perfect example of why piling on solutions is such a bad
strategy.
Much better to go back to first principles and design carefully. Just
harder to do, because it requires both questioning assumptions and thinking
hard about users (and devices) and their goals.
On Sat, Jul 19, 2014 at 4:26 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> On 19/07/2014 19:51, Birkir R. Gunnarsson wrote:
>
>> Whenever you see positive tabindex being used, I would recommend
>> calling that out as a potential user issue and recommend that it be
>> avoided at all cost.
>>
>
> Tiny sidenote that, from my very cursory testing in iOS/Safari at least,
> mobile/tablet browsers ignore tabindex > 0 when you navigate with AT and/or
> keyboard...so if tabindex is used to try and force a certain sensible order
> due to underlying HTML / source order of focusable elements being wrong,
> then note that on these platforms that won't have the desired effect and
> the wrong tab cycle will still be there for users.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
> > > >
From: David Ashleydale
Date: Mon, Jul 21 2014 10:11AM
Subject: Re: Partial Tabindex Behavior
← Previous message | No next message
Perfectly stated, Whitney.
David
On Monday, July 21, 2014, Whitney Quesenbery < = EMAIL ADDRESS REMOVED = > wrote:
> Would be unfair to say that TabIndex was a bandaid.
>
> And that it can cause as much harm as good.
>
> And that getting back to good design is a better solution -- in this case,
> designing for a logical keyboard sequence.
>
> This seems to me a perfect example of why piling on solutions is such a bad
> strategy.
>
> Much better to go back to first principles and design carefully. Just
> harder to do, because it requires both questioning assumptions and thinking
> hard about users (and devices) and their goals.
>
>
> On Sat, Jul 19, 2014 at 4:26 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED =
> <javascript:;>>
> wrote:
>
> > On 19/07/2014 19:51, Birkir R. Gunnarsson wrote:
> >
> >> Whenever you see positive tabindex being used, I would recommend
> >> calling that out as a potential user issue and recommend that it be
> >> avoided at all cost.
> >>
> >
> > Tiny sidenote that, from my very cursory testing in iOS/Safari at least,
> > mobile/tablet browsers ignore tabindex > 0 when you navigate with AT
> and/or
> > keyboard...so if tabindex is used to try and force a certain sensible
> order
> > due to underlying HTML / source order of focusable elements being wrong,
> > then note that on these platforms that won't have the desired effect and
> > the wrong tab cycle will still be there for users.
> >
> > P
> > --
> > Patrick H. Lauke
> >
> > www.splintered.co.uk | https://github.com/patrickhlauke
> > http://flickr.com/photos/redux/ | http://redux.deviantart.com
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> >
> > > > > > > >
> > > >