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 22, 2016 6:14AM

I agree with you Kliff.
Hi Joe,

If the focus is moved to the modal container, I was wondering screen reader
may read the content of the entire modal or if it restrict to the content
called by aria-describedby.
The other problem I observe commonly is the screen reader moves to forms
mode when role dialog is used. This means screen reader user should switch
to browse mode and then read the content on the modal.


On Mon, Mar 21, 2016 at 4:58 PM, Joe Chidzik < <EMAIL REMOVED> >
wrote:

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