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