WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Joe Chidzik
Date: Mar 21, 2016 5:28AM

In this case though, the developer should probably use tabindex="-1" which restricts the focus to only being placed onto an element programmatically, rather than the element appearing in the focus order with tabindex="0".

As an aside, I would probably place the focus onto the actual dialog container itself (with role=dialog), rather than the heading, with the title of this container picked up from the dialog heading via aria-describedby or similar.

Joe

> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ]
> On Behalf Of Maxability Accessibility for all
> Sent: 20 March 2016 17:45
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] WCAG Violation for use of tabindex=0 on static
> elements.
>
> 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:webaim-forum-
> <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:webaim-forum-
> <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
> > >> > > >> > > >> > > >> archives at http://webaim.org/discussion/archives
> > >> > > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > http://webaim.org/discussion/archives
>