WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: James Nurthen
Date: Mar 16, 2016 5:56PM

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
> > > > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >