WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG Violation for use of tabindex=0 on static elements.

for

From: Jeevan Reddy
Date: Mar 21, 2016 4:46AM

i see it as usability issue more than accessibility issue for low
vision and keyboard users.
modern browsers provide focus indicator(2.4.7) for the elements
having tabindex greator or equal to zero but may not be sufficient for
low vision users in order to keep track where they are in.
adding tabindex for more elements in a page, for example for the hint
text in a form, force the keyboard users to use more tabs while
navigating.
The real example of adding tab index for non static elements which is
absolutely required is the terms and conditions in a dialog. todays Ux
showing that unless the user scroll through the list of terms and
conditions the dialog proceed and cancel buttons will not be enabled.

if you wish todo so consider 2.4.7
On 3/21/16, Cliff Tyllick < <EMAIL REMOVED> > wrote:
> Rakesh, I see no violation there. In fact, even when the first element in
> the modal is just a paragraph, there is no violation. As Andrew pointed out,
> <p> assigns the proper role for body text just as effectively as <h1>
> through <h6> assign the proper roles for headings.
>
> I can't think of situations that show more clearly than these two why
> tabindex="0" is needed at all:
> - Having to direct focus to the beginning of the contents of a modal window.
> - Having to ensure that instructions needed to correctly complete a form
> appear in the tab order exactly where they are needed.
>
> Cheers!
>
> Cliff Tyllick
> Accessibility Specialist
> Texas Department of Assistive and Rehabilitative Services
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its
> fault.
>
>> On Mar 20, 2016, at 10:45 AM, Maxability Accessibility for all
>> < <EMAIL REMOVED> > wrote:
>>
>> If we consider having tabindex for static content as violation whats your
>> stand on the following situation.
>> When the user activate a link on the page it opens a modal. The modal has
>> a
>> heading as first element. To set focus on to the first element on the
>> modal
>> when it is opened the developer has used tabindex=0 to the heading in the
>> modal.
>> In this case to fix a problem related to 2.4.3 focus order tabindex is
>> used. In this case I think heading role is already provided through the
>> native control, so no 4.1.2 violation. May be other checkpoints such as
>> 2.4.7 etc comes into force.
>> Any thoughts.
>>
>> Thanks & Regards
>> Rakesh
>>
>> On Fri, Mar 18, 2016 at 12:34 AM, Kevin Prince < <EMAIL REMOVED> >
>> wrote:
>>
>>> Thanks for this discussion. I have had to use precisely this hack to
>>> expose helper text in a form where the backend doesn't allow for aria or
>>> for html to attach the helper text to the field. I'd argue that, in my
>>> case, these are actionable - they are elements of the form that you need
>>> to
>>> read to complete it, the focus is correctly indicated and it's the lesser
>>> of two evils. Having 3 tabstops for a heading isn't logical though so
>>> fails
>>> for me without any stretch of WCAG.
>>>
>>> Kev
>>> Access1in5
>>> 0212220638
>>> 039290692
>>> Independent Accessibility and IT Consultancy.
>>>
>>>
>>>
>>>> On 18/03/2016, at 02:55, Andrew Kirkpatrick < <EMAIL REMOVED> > wrote:
>>>>
>>>> This is definitely an area that I'd like to see clarified in the
>>> future. I would argue that text _is_ a user interface component, and if
>>> you have:
>>>>
>>>> <p tabindex=0>Some text</p>
>>>>
>>>> You have set the name and role by using a paragraph and by the paragraph
>>> having the text content. The browser may report the element as clickable
>>> (the state), so some of these concerns may actually be addressed. Of
>>> course there are accessibility support issues, but we will put that aside
>>> for now.
>>>>
>>>> The questions that I have about this type of interaction (apart from "is
>>> this really necessary?") are:
>>>> Will a screen reader user know that this is a link or provides some
>>> other interaction and if so, know how to activate it and what it is for?
>>> (perhaps 2.4.4 if the effect is that a link is created, or 1.1.1 to make
>>> sure that the control has a name that describes the input, 4.1.2 just
>>> requires a name - 1.1.1 requires that it describes the purpose)
>>>>
>>>> Will a sighted keyboard user be able to know that this control is
>>> interactive and how to use it? (SC 2.4.7 for focus visibility. The how
>>> to
>>> use it is likely a question that will affect all users)
>>>>
>>>> So I would say that 1.1.1 and 2.4.7 are SC that I'd look at for this.
>>>>
>>>> Thanks,
>>>> AWK
>>>>
>>>> Andrew Kirkpatrick
>>>> Group Product Manager, Accessibility
>>>> Adobe
>>>>
>>>> <EMAIL REMOVED>
>>>> http://twitter.com/awkawk
>>>> http://blogs.adobe.com/accessibility
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 3/16/16, 20:30, "WebAIM-Forum on behalf of Jonathan Avila" <
>>> <EMAIL REMOVED> on behalf of
>>> <EMAIL REMOVED> > wrote:
>>>>
>>>>>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now
>>> applies to these traditionally non-widget components
>>>>>
>>>>> This brings up a question I have always wondered -- what role can you
>>> apply to text? None? Presentation? There are some rare situations where
>>> you may want to place text in the focus order and if you do -- what role
>>> would you be required to use in order for it to meet SC 4.1.2?
>>>>>
>>>>> Jonathan
>>>>>
>>>>>