WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan Avila
Date: Mar 16, 2016 6:30PM

> 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
> >