E-mail List Archives
Thread: Misuse of TabIndex 0
Number of posts in this thread: 12 (In chronological order)
From: Moore,Michael (Accessibility) (HHSC)
Date: Wed, Nov 04 2015 7:59AM
Subject: Misuse of TabIndex 0
No previous message | Next message →
I am evaluating a large web based application that uses tabindex="0" to place all of the explanatory text, instructions, FAQ's, questions for groups of radio buttons and checkboxes, etc. into the tab ring.
I am of the opinion that this violates the intent if not the letter of guideline 2.4.3 focus order. "If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability"
My interpretation is that by placing inactive/static content within the tab ring operability is severely adversely impacted for people who depend upon tab navigation.
Operability is impacted in the following ways:
1. Additional tab stops make it harder to get to interactive controls like links and form fields. This is particularly onerous for people who use keyboard navigation due to a physical disability that limits dexterity in their hands.
2. The additional tab stops may create confusion since the user will expect to tab to controls, form fields and links and not static text.
3. The additional tab stops may create further confusion since some users may assume that since the text is focusable that it will be actionable (This may also violate 4.1.2).
Do you agree or disagree with my interpretation and why? Is there another guideline at level A or AA that may apply here? Note: 2.4.7 Focus Visible is being met.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
From: Paul J. Adam
Date: Wed, Nov 04 2015 8:47AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
You could fail it for name, role, value because they're using a focusable element that should have a role that indicates keyboard operability but static text is not keyboard operable.
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On Nov 4, 2015, at 8:59 AM, Moore,Michael (Accessibility) (HHSC) < = EMAIL ADDRESS REMOVED = > wrote:
>
> I am evaluating a large web based application that uses tabindex="0" to place all of the explanatory text, instructions, FAQ's, questions for groups of radio buttons and checkboxes, etc. into the tab ring.
>
> I am of the opinion that this violates the intent if not the letter of guideline 2.4.3 focus order. "If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability"
>
> My interpretation is that by placing inactive/static content within the tab ring operability is severely adversely impacted for people who depend upon tab navigation.
>
> Operability is impacted in the following ways:
>
> 1. Additional tab stops make it harder to get to interactive controls like links and form fields. This is particularly onerous for people who use keyboard navigation due to a physical disability that limits dexterity in their hands.
>
> 2. The additional tab stops may create confusion since the user will expect to tab to controls, form fields and links and not static text.
>
> 3. The additional tab stops may create further confusion since some users may assume that since the text is focusable that it will be actionable (This may also violate 4.1.2).
>
> Do you agree or disagree with my interpretation and why? Is there another guideline at level A or AA that may apply here? Note: 2.4.7 Focus Visible is being met.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> > > >
From: Patrick H. Lauke
Date: Wed, Nov 04 2015 8:47AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
On 04/11/2015 14:59, Moore,Michael (Accessibility) (HHSC) wrote:
[...]
> Do you agree or disagree with my interpretation and why?
Yes, for the reasons you listed.
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: Steve Faulkner
Date: Wed, Nov 04 2015 9:32AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
Furthermore making elements focusable that don't have the appropriate roles
exposed leads to odd behavious in some screen readers as the interpret the
elements as editable text or they announce all text content as the
accessible name for the element on focus and some other unexpected nasties.
This is not the AT's fault as the addition of tabindex=0 modifies the
representation of an element in the accessibility tree and how its
accessible name is generated.
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 4 November 2015 at 14:59, Moore,Michael (Accessibility) (HHSC) <
= EMAIL ADDRESS REMOVED = > wrote:
> I am evaluating a large web based application that uses tabindex="0" to
> place all of the explanatory text, instructions, FAQ's, questions for
> groups of radio buttons and checkboxes, etc. into the tab ring.
>
> I am of the opinion that this violates the intent if not the letter of
> guideline 2.4.3 focus order. "If a Web page can be navigated sequentially
> and the navigation sequences affect meaning or operation, focusable
> components receive focus in an order that preserves meaning and operability"
>
> My interpretation is that by placing inactive/static content within the
> tab ring operability is severely adversely impacted for people who depend
> upon tab navigation.
>
> Operability is impacted in the following ways:
>
> 1. Additional tab stops make it harder to get to interactive controls
> like links and form fields. This is particularly onerous for people who use
> keyboard navigation due to a physical disability that limits dexterity in
> their hands.
>
> 2. The additional tab stops may create confusion since the user will
> expect to tab to controls, form fields and links and not static text.
>
> 3. The additional tab stops may create further confusion since some
> users may assume that since the text is focusable that it will be
> actionable (This may also violate 4.1.2).
>
> Do you agree or disagree with my interpretation and why? Is there another
> guideline at level A or AA that may apply here? Note: 2.4.7 Focus Visible
> is being met.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> > > > >
From: Jared Smith
Date: Wed, Nov 04 2015 9:59AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
While making non-interactive elements navigable is certainly an issue,
you also should realize that removing the elements from the tab flow
entirely may result in other issues. When navigating through a form,
important instructions and cues between form controls will often be
skipped over. Lengthy questions that are associated as legends for an
answer set are very burdensome to have read for EVERY control in the
fieldset.
These are problems for which there are not good solutions - and
perhaps there are instances where tabindex=0 on these elements is less
of an end user issue than the alternative.
Jared
From: Paul J. Adam
Date: Wed, Nov 04 2015 10:06AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
That's why input instructions and error messages must be programmatically associated with the inputs.
Not all screen readers speak the <legend> text for each input in the <fieldset>, NVDA speaks it only once for each group when entering the <fieldset>, same with TalkBack/Firefox. VoiceOver OS X speaks it once for each input in the group only if you're TABing but if you're using VO+arrow keys it does not speak the <legend> for each input. VoiceOver iOS does not speak the legend for any of the inputs, the legend is simply static text.
I would think the solution is to use ARIA to connect any instructions to the specific input that requires them and then the screen reader will speak them aloud while TABing through the form. That way there's no need to add any extra TAB stops.
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On Nov 4, 2015, at 10:59 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> While making non-interactive elements navigable is certainly an issue,
> you also should realize that removing the elements from the tab flow
> entirely may result in other issues. When navigating through a form,
> important instructions and cues between form controls will often be
> skipped over. Lengthy questions that are associated as legends for an
> answer set are very burdensome to have read for EVERY control in the
> fieldset.
>
> These are problems for which there are not good solutions - and
> perhaps there are instances where tabindex=0 on these elements is less
> of an end user issue than the alternative.
>
> Jared
> > > >
From: Bryan Garaventa
Date: Wed, Nov 04 2015 10:43AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
Precisely, adding aria-describedby on any active element with a role, whether ARIA based or implicit like a standard form field or link, will be announced when tabbing to it. The aria-describedby attribute also accepts multiple ID references separated by spaces for non-contiguous messages, and since this sets the Description property in the Accessibility Tree, it doesn't interfere with the Name calculation. E.G
http://whatsock.com/training/matrices/visual-aria.htm#name-calculation
This is much more useful than setting tabindex="0" on everything, because it is totally unobtrusive.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul J. Adam
Sent: Wednesday, November 04, 2015 9:07 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Misuse of TabIndex 0
That's why input instructions and error messages must be programmatically associated with the inputs.
Not all screen readers speak the <legend> text for each input in the <fieldset>, NVDA speaks it only once for each group when entering the <fieldset>, same with TalkBack/Firefox. VoiceOver OS X speaks it once for each input in the group only if you're TABing but if you're using VO+arrow keys it does not speak the <legend> for each input. VoiceOver iOS does not speak the legend for any of the inputs, the legend is simply static text.
I would think the solution is to use ARIA to connect any instructions to the specific input that requires them and then the screen reader will speak them aloud while TABing through the form. That way there's no need to add any extra TAB stops.
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On Nov 4, 2015, at 10:59 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> While making non-interactive elements navigable is certainly an issue,
> you also should realize that removing the elements from the tab flow
> entirely may result in other issues. When navigating through a form,
> important instructions and cues between form controls will often be
> skipped over. Lengthy questions that are associated as legends for an
> answer set are very burdensome to have read for EVERY control in the
> fieldset.
>
> These are problems for which there are not good solutions - and
> perhaps there are instances where tabindex=0 on these elements is less
> of an end user issue than the alternative.
>
> Jared
> > > archives at http://webaim.org/discussion/archives
>
From: Jared Smith
Date: Wed, Nov 04 2015 11:09AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
Paul J. Adam wrote:
> That's why input instructions and error messages must be programmatically associated with the inputs.
What if the instructions are relevant to numerous inputs? Should they
be associated to all of them? This would be burdensome. Only the first
one? This would not really be accurate.
And what if the instructions include semantics or functional elements
which would be lost when attached as a label or description?
I fully agree that tabindex=0 is a bad solution, but it's sometimes
used to address problems for which there isn't a good solution.
Jared
From: Paul J. Adam
Date: Wed, Nov 04 2015 12:53PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
Need a specific example to say how I'd make it accessible but I've never seen a form with a set of text instructions that needed to be programmatically associated with every input. Other than maybe "All fields marked * are required" but that would be handled with aria-required=true and the * inside the label.
If the instructions are say a data table then the user would be expected to manually read the data table as you could not programmatically associate an entire table with an input. You could maybe connect the table's caption element to the input and the user would hear the table's title spoken when tabbing into that input.
I see tabindex=0 on instructional text more as an accessibility misunderstanding/"old-school hack" where the person implanting the accessibility fix thinks that screen reader users only TAB through everything and don't use linear navigation or quick navigation keys.
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On Nov 4, 2015, at 12:09 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
> Paul J. Adam wrote:
>> That's why input instructions and error messages must be programmatically associated with the inputs.
>
> What if the instructions are relevant to numerous inputs? Should they
> be associated to all of them? This would be burdensome. Only the first
> one? This would not really be accurate.
>
> And what if the instructions include semantics or functional elements
> which would be lost when attached as a label or description?
>
> I fully agree that tabindex=0 is a bad solution, but it's sometimes
> used to address problems for which there isn't a good solution.
>
> Jared
> > > >
From: Graham Armfield
Date: Thu, Nov 05 2015 3:14AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
But mindful of Jared's point, if I'm using a screen reader within a form
then surely I'm much more likely to be using the tab key to move around
than if I'm a plain content are (for want of a better description).
Regards
Graham Armfield
âWeb Accessibility Consultantâ
From: Moore,Michael (Accessibility) (HHSC)
Date: Thu, Nov 05 2015 9:38AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →
Far more people than just screen reader users use tab navigation to move through a form. Adding unneeded tab stops to make everything on the form readable through the tab ring does a disservice to those users and provides screen reader users and others. It implicitly implies that all of the tab-able objects have a role of active. Far better to use aria-labelledby and aria-described by to make sure that critical information is not lost to a screen reader user. See comments on this thread from Steve Faulkner and Paul Adam.
Modern screen reader software has an auto forms mode allowing the use of reading keys to navigate a form rather than just tabbing through. I am not saying that you would never use tab-index of 0 on a static object. There may be a rare use case when it is the only way to make an object accessible. But if the only purpose of tab-index 0 is to make sure that a screen reader user cannot avoid reading the instructions then you are denying them the same opportunity that anyone else has to ignore the instructions. It may be that they have already filled out the form 10 times before and don't need to read the instructions again.
Much better form design is to use headings to define sections of a form and provide the instructions for each section immediately after the heading and before the fields start. Screen reader users will receive information about the number of headings when the form opens and will know that there are multiple sections. I could even see using aria-describedby or aria-label on the last field in a section to notify a screen reader user that this is the end of the section. This would be unobtrusive for other users and would not adversely impact the tab-order or the implicit roles of the objects in the form.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Graham Armfield
Sent: Thursday, November 05, 2015 4:15 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Misuse of TabIndex 0
But mindful of Jared's point, if I'm using a screen reader within a form then surely I'm much more likely to be using the tab key to move around than if I'm a plain content are (for want of a better description).
Regards
Graham Armfield
âWeb Accessibility Consultantâ
From: Kinnunen,Daniel (DARS)
Date: Thu, Nov 05 2015 1:32PM
Subject: Re: Misuse of TabIndex 0
← Previous message | No next message
Steven, are you saying that using tabindex=0 on static text (e.g., <p tabindex="0"> is an automatic failure of WCAG 4.1.2?
Dan Kinnunen
Accessibility Coordinator
Texas Department of Assistive and Rehabilitative Services
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Steve Faulkner
Sent: Wednesday, November 04, 2015 10:32 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Misuse of TabIndex 0
Furthermore making elements focusable that don't have the appropriate roles exposed leads to odd behavious in some screen readers as the interpret the elements as editable text or they announce all text content as the accessible name for the element on focus and some other unexpected nasties.
This is not the AT's fault as the addition of tabindex=0 modifies the representation of an element in the accessibility tree and how its accessible name is generated.
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 4 November 2015 at 14:59, Moore,Michael (Accessibility) (HHSC) < = EMAIL ADDRESS REMOVED = > wrote:
> I am evaluating a large web based application that uses tabindex="0"
> to place all of the explanatory text, instructions, FAQ's, questions
> for groups of radio buttons and checkboxes, etc. into the tab ring.
>
> I am of the opinion that this violates the intent if not the letter of
> guideline 2.4.3 focus order. "If a Web page can be navigated
> sequentially and the navigation sequences affect meaning or operation,
> focusable components receive focus in an order that preserves meaning and operability"
>
> My interpretation is that by placing inactive/static content within
> the tab ring operability is severely adversely impacted for people who
> depend upon tab navigation.
>
> Operability is impacted in the following ways:
>
> 1. Additional tab stops make it harder to get to interactive controls
> like links and form fields. This is particularly onerous for people
> who use keyboard navigation due to a physical disability that limits
> dexterity in their hands.
>
> 2. The additional tab stops may create confusion since the user will
> expect to tab to controls, form fields and links and not static text.
>
> 3. The additional tab stops may create further confusion since some
> users may assume that since the text is focusable that it will be
> actionable (This may also violate 4.1.2).
>
> Do you agree or disagree with my interpretation and why? Is there
> another guideline at level A or AA that may apply here? Note: 2.4.7
> Focus Visible is being met.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission Civil Rights Office
> > > archives at http://webaim.org/discussion/archives
> >