WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Maxability Accessibility for all
Date: Mar 20, 2016 11:45AM

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
> >>
> >> -----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
> >>> > >>>
> >> > >> > archives at http://webaim.org/discussion/archives
> >> > >> > >> > >> > >> > > > > > > > > >
> > > > >