WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Birkir R. Gunnarsson
Date: Mar 17, 2016 7:49AM

off-otpic
Coincidence?
I doubt it.
I have had the privellege to work with and receive training from some
pretty awesome accessibility people.

Sailesh is one of the Deque folks who taught me the most about accessibility.
So did many people ouside of Deque such as Bryan Garaventa, Denis
Boudreau, the WebAIM folks, and a lot of people on this list (if I
started naming all the names it would end up being a long email and
awfully off-topic).
But I must take a moment to say thank you to everyone on this list who
help me, from the moment I first heard about web accessibility 7 or 8
years ago, to where I am today.
And big thanks to Jared and the WebAIM folks who have kept this list
going for almost a decade.

I hope to help pass the knowledge on to others so we can all help make
the web an equal opportunity universe.
end-of-off-topic.
Cheers
-B



On 3/17/16, Sailesh Panchang < <EMAIL REMOVED> > wrote:
> Birkir beat me to it and in fact took the words out of my mouth!
> It is a fail under all the 3 SCs he listed.
> Thanks,
> Sailesh
>
>
>
>
> On 3/16/16, Jonathan Avila < <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
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
>> Of James Nurthen
>> Sent: Wednesday, March 16, 2016 7:57 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] WCAG Violation for use of tabindex=0 on static
>> elements.
>>
>> I agree with 4.1.2
>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now applies
>> to these traditionally non-widget components
>>
>> As such they need to have an accessible name and the "correct" role
>> exposed
>> to the Accessibility APIs. They now take focus so the non-widget roles
>> they
>> have are not valid for these now interactive components.
>>
>> Regards,
>> James
>>
>>
>>
>>
>> On Wed, Mar 16, 2016 at 3:02 PM, Birkir R. Gunnarsson <
>> <EMAIL REMOVED> > wrote:
>>
>>> Lucy!
>>> I like your style!
>>> If we are still talking WCAG I have 3 suggestions:
>>> First, 2.4.7 .. when you tab through all of these, do you always see
>>> where the focus is? I am highly suspicious that a focus indicator has
>>> not been created around all the static elements with tabindex="0",
>>> therefore 2.4.7 fails.
>>> If that is true, I think the case for 2.4.3 is much strengthened.
>>> User expects to be tabbing from one actionable element to the next.
>>> If he tabs, loses sight of where he is, tries to activate the element,
>>> and nothing happens, that would be hard to interpret as a logical
>>> focus order.
>>> The third is 4.1.2, name, role, value.
>>> You expect that an element that receives focus is an actionable element.
>>> Actionable elements have to have a role. divs and spans do not have a
>>> role, and that matters when you can tab to them.
>>>
>>> I hope that none of the creative WCAG interpretation thinking is needed.
>>> This must be due to wanting to accommodate for accessibility without
>>> fully understanding how.
>>> I once audited a webpage which had access key attributes for every
>>> link and piece of text on the page (they stopped because they ran out
>>> of keys).
>>>
>>>
>>>
>>>
>>>
>>> On 3/16/16, Moore,Michael (Accessibility) (HHSC)
>>> < <EMAIL REMOVED> > wrote:
>>> > "Any accessibility effort that is so reliant upon WCAG that it
>>> > neglects
>>> to
>>> > address end user issues that are not defined as WCAG failures will
>>> > rarely result in good accessibility."
>>> >
>>> > I totally agree but am going for the stretch argument anyway.
>>> > Otherwise
>>> it
>>> > probably will not be fixed.
>>> >
>>> > Mike Moore
>>> > Accessibility Coordinator
>>> > Texas Health and Human Services Commission Civil Rights Office
>>> >
>>> > -----Original Message-----
>>> > From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>>> Behalf
>>> > Of Jared Smith
>>> > Sent: Wednesday, March 16, 2016 3:19 PM
>>> > To: WebAIM Discussion List < <EMAIL REMOVED> >
>>> > Subject: Re: [WebAIM] WCAG Violation for use of tabindex=0 on static
>>> > elements.
>>> >
>>> >> Are there specific WCAG AA guidelines that I can cite for this
>>> >> problem?
>>> >
>>> > I don't think so. 2.1.1 only requires that functionality be operable
>>> > via
>>> a
>>> > keyboard - which it is. It doesn't indicate anything about
>>> > efficiency, having non-actionable elements placed in the keyboard
>>> > navigation flow,
>>> etc.
>>> >
>>> > F44, as Marc suggested, is quite a stretch. It deals with defining a
>>> > navigation order that is not logical. In your situation, the order
>>> > is logical - it's just that there's a lot of useless navigation
>>> > elements
>>> thrown
>>> > into the mix.
>>> >
>>> > Despite what WCAG requires, this is clearly an issue for end users
>>> > and should be fixed.
>>> >
>>> > Any accessibility effort that is so reliant upon WCAG that it
>>> > neglects to address end user issues that are not defined as WCAG
>>> > failures will rarely result in good accessibility.
>>> >
>>> > Jared
>>> > >>> > >>> archives at
>>> > http://webaim.org/discussion/archives
>>> > >>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> >
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> at
>> http://webaim.org/discussion/archives
>> >> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.