E-mail List Archives
Thread: Tab Order and Focus Question
Number of posts in this thread: 11 (In chronological order)
From: Jim Homme
Date: Tue, Mar 12 2019 10:00AM
Subject: Tab Order and Focus Question
No previous message | Next message →
Hi,
The Understanding 4.1.2 page at https://www.w3.org/WAI/WCAG21/Understanding/name-role-value talks about controls receiving focus. Since I'm a screen reader user, this may be a sighted question. It is possible to give tab order to items that are not controls. My question is: does that mean that these items receive focus if they are in the tab order?
Thanks.
Jim
==========
Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
From: Isabel Holdsworth
Date: Tue, Mar 12 2019 10:04AM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Hi Jim,
Yes, if an element has a tabindex, either assigned implicitly because
it's a natively interactive control such as a link or form control, or
a custom widget that's been given an explicit tabindex, then it can
receive focus.
Even elements with a tabindex of "-1" can received focus, although
only via scripting rather than using the Tab key.
Cheers, Isabel
On 12/03/2019, Jim Homme < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
> The Understanding 4.1.2 page at
> https://www.w3.org/WAI/WCAG21/Understanding/name-role-value talks about
> controls receiving focus. Since I'm a screen reader user, this may be a
> sighted question. It is possible to give tab order to items that are not
> controls. My question is: does that mean that these items receive focus if
> they are in the tab order?
>
> Thanks.
>
> Jim
>
>
>
> ==========
> Jim Homme
> Digital Accessibility
> Bender Consulting Services
> 412-787-8567
> https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
>
> > > > >
From: mhysnm1964
Date: Wed, Mar 13 2019 1:52AM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Jim,
Anything in the web or any program can receive focus. Tabindex is the
attribute which permits the keyboard focus to land on an element. If the
element should receive focus is a different story.
From: Isabel Holdsworth
Date: Wed, Mar 13 2019 8:00AM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Hi Jim,
If it's in the tab order, either natively or by means of an assigned
tabindex, it can receive focus, in which case it should have an
identifiable name, role, value and focus outline.
Cheers, Isabel
On 13/03/2019, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> Jim,
>
> Anything in the web or any program can receive focus. Tabindex is the
> attribute which permits the keyboard focus to land on an element. If the
> element should receive focus is a different story.
>
>
From: Jim Homme
Date: Fri, Mar 15 2019 2:51PM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Hi,
I was asking if the visual indicator for focus is the same when focus is not on interactive elements.
==========
Jim Homme
Digital Accessibility
Bender Consulting Services
412-787-8567
https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
From: Mallory
Date: Fri, Mar 15 2019 4:59PM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Yes, including the example mentioned earlier of something with tabindex="-1" and JavaScript sets focus. If the developer didn't remove it, focus should be visible.
cheers,
_mallory
On Fri, Mar 15, 2019, at 9:51 PM, Jim Homme wrote:
> Hi,
> I was asking if the visual indicator for focus is the same when focus
> is not on interactive elements.
>
>
>
> ==========
> Jim Homme
> Digital Accessibility
> Bender Consulting Services
> 412-787-8567
> https://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
From: glen walker
Date: Fri, Mar 15 2019 5:26PM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Ahh, now I understand Jim's original question. You're asking if a
non-interactive element receives focus (for whatever reason), should it
have a visible focus indicator?
That's an interesting question. My take on it is that it is not required
by WCAG.
4.1.2 talks about focus but it's for "User Interface Components", with the
definition <https://www.w3.org/TR/WCAG21/#dfn-user-interface-components>
saying "What is meant by "component" or "user interface component" here is
also sometimes called "user interface element"."
2.4.7 says the focus must be visible for a "keyboard operable user
interface".
So a non-natively focusable element that happens to have tabindex=0 so that
users can tab to it, if it's not an element that can be acted upon (a user
interface component), then it doesn't need a focus indicator according to
the spec. (We'll ignore for the moment that non-interactive elements
shouldn't have tabindex=0).
If you use tabindex="-1" so that you can programmatically move the focus to
the element, for example the destination of a skip link, or a heading in a
single page app, or a modal dialog container, then since those elements are
not interactive, they don't need a focus indicator either. That doesn't
mean you can't do some kind of visual styling to show the element received
focus. For example, the WebAIM site will show a focus indicator briefly
when using the skip link even though the destination of the skip link is
not an interactive element. The background of the element (which in this
case is a big <div>) goes yellow then fades away. It gives you a clue that
the focus changed. If they didn't have that indicator, it would still pass
WCAG but it's a nice UX addition.
On Fri, Mar 15, 2019 at 5:00 PM Mallory < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, including the example mentioned earlier of something with
> tabindex="-1" and JavaScript sets focus. If the developer didn't remove it,
> focus should be visible.
>
> cheers,
> _mallory
>
> On Fri, Mar 15, 2019, at 9:51 PM, Jim Homme wrote:
> > Hi,
> > I was asking if the visual indicator for focus is the same when focus
> > is not on interactive elements.
> >
>
>
From: Guy Hickling
Date: Fri, Mar 15 2019 6:52PM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Perhaps it will help to clarify all this if we consider why it would be
necessary to put a tabindex on a non-interactive control.
Sadly there is huge need for it because unfortunately far too many
designers and developers want to custom build their own interactive
components instead of using the HTML ones. (Some do it to radio buttons
just to make them look bigger, and make a huge accessibility mess if it in
doing so.) And sadly (this is a very sad subject!) a lot of frameworks and
JavaScript libraries do the same thing. The usual thing is to use div or
span elements and turn them into something interactive using JavaScript
event listeners to handle the mouse clicks and, except sadly most of them
forget to do this, keypress events as well.
Probably something approaching half of all websites do this sort of thing
at least once. Since divs and spans are not interactive, adding a tabindex
of 0 is necessary otherwise keyboard users won't be able to tab onto the
fancy new component.
And keyboard event handlers to pick up Enter or Spacebar key presses, or
whatever keys the component should correctly be using, are also necessary
for keyboard users to operate the control having landed on it.
Browsers automatically give the button click() event Enter and spacebar
handling ability without those needing to be added, but they don't usually
do this for customised divs and spans.
That's why keyboard users so frequently can't get to or use custom
interactive components, because the developer doesn't know to give them
either or both of a tabindex and key handlers. (Screen readers will usually
allow navigation onto the component even though keyboard-only users can't
get to it.)
*Popup dialogs*
Another use case for tabindex is on modal popups. If there is a Close
button in the top right corner focus is usually placed on that when the
dialog opens, and most instructions about popup dialogs say to place focus
on the first interactive control. (And a tabindex will be needed on the
Close button as well if it is only a link with no href as is often the
case.)
But if the only interactive component on a large dialog full of text is
down at the bottom of it, then it makes better sense for the user if focus
is placed at the top, either on the dialog container, or on it's main
heading. Again, that will need tabindex="-1" so focus can be placed on it
by the JavaScript.
*Too many tabindexes*
So the need for tabindex is very common. Sadly (I said this was a very sad
subject, altogether too many sadlies!) there are still some old websites
where the developer splurged tabindexes greater than zero all over the page
on every interactive control in the place. Which generally leads to very
cute and confusing tab orders and should never be done of course. It
doesn't seem to happen so much these days.
Regards,
Guy Hickling
From: glen walker
Date: Sat, Mar 16 2019 1:26AM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
Yes, those are all very good reasons for having a tabindex on a natively
non-interactive element that wants to be interactive, but that's not what I
was talking about. I was talking about non-interactive elements. Those
should never have tabindex=0. Only (occasionally), tabindex=-1.
On Fri, Mar 15, 2019 at 6:52 PM Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
> Perhaps it will help to clarify all this if we consider why it would be
> necessary to put a tabindex on a non-interactive control.
>
>
From: Mallory
Date: Wed, Mar 20 2019 6:02AM
Subject: Re: Tab Order and Focus Question
← Previous message | Next message →
I would however argue that if someone is, for whatever reason, foolish enough to set a tabindex on a non-interactive element (such as I recently saw in the Stemwijzer here in the Netherlands), then if they do not show a focus indication, then I as a sighted keyboard user am at a loss. Where am I? Separate from the issue of having focus on things that don't seem to do anything being confusing in and of itself, I feel letting me hit Tab and not seeing anything happening is wrong. Probably double wrong if I'm using screen magnification and using Tab moves my viewport to a focussed thing which does not appear focussed.
cheers,
_mallory
On Sat, Mar 16, 2019, at 12:27 AM, glen walker wrote:
> Ahh, now I understand Jim's original question. You're asking if a
> non-interactive element receives focus (for whatever reason), should it
> have a visible focus indicator?
>
> That's an interesting question. My take on it is that it is not required
> by WCAG.
>
> 4.1.2 talks about focus but it's for "User Interface Components", with the
> definition <https://www.w3.org/TR/WCAG21/#dfn-user-interface-components>
> saying "What is meant by "component" or "user interface component" here is
> also sometimes called "user interface element"."
>
> 2.4.7 says the focus must be visible for a "keyboard operable user
> interface".
>
> So a non-natively focusable element that happens to have tabindex=0 so that
> users can tab to it, if it's not an element that can be acted upon (a user
> interface component), then it doesn't need a focus indicator according to
> the spec. (We'll ignore for the moment that non-interactive elements
> shouldn't have tabindex=0).
>
> If you use tabindex="-1" so that you can programmatically move the focus to
> the element, for example the destination of a skip link, or a heading in a
> single page app, or a modal dialog container, then since those elements are
> not interactive, they don't need a focus indicator either. That doesn't
> mean you can't do some kind of visual styling to show the element received
> focus. For example, the WebAIM site will show a focus indicator briefly
> when using the skip link even though the destination of the skip link is
> not an interactive element. The background of the element (which in this
> case is a big <div>) goes yellow then fades away. It gives you a clue that
> the focus changed. If they didn't have that indicator, it would still pass
> WCAG but it's a nice UX addition.
>
> On Fri, Mar 15, 2019 at 5:00 PM Mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Yes, including the example mentioned earlier of something with
> > tabindex="-1" and JavaScript sets focus. If the developer didn't remove it,
> > focus should be visible.
> >
> > cheers,
> > _mallory
> >
> > On Fri, Mar 15, 2019, at 9:51 PM, Jim Homme wrote:
> > > Hi,
> > > I was asking if the visual indicator for focus is the same when focus
> > > is not on interactive elements.
> > >
> >
> >
> > > > >
From: glen walker
Date: Wed, Mar 20 2019 9:30AM
Subject: Re: Tab Order and Focus Question
← Previous message | No next message
Ignoring the wrongness of tabindex="0" on a non-interactive element, I
agree that the focus indicator disappearing can be confusing and should
never happen, but I think the original question was if WCAG required a
focus indicator on non-interactive elements. My interpretation is that it
is not required. That doesn't mean you shouldn't show one, as I indicated
in my previous reply, but it's not required.
On Wed, Mar 20, 2019 at 6:02 AM Mallory < = EMAIL ADDRESS REMOVED = > wrote:
> I would however argue that if someone is, for whatever reason, foolish
> enough to set a tabindex on a non-interactive element (such as I recently
> saw in the Stemwijzer here in the Netherlands), then if they do not show a
> focus indication, then I as a sighted keyboard user am at a loss. Where am
> I? Separate from the issue of having focus on things that don't seem to do
> anything being confusing in and of itself, I feel letting me hit Tab and
> not seeing anything happening is wrong. Probably double wrong if I'm using
> screen magnification and using Tab moves my viewport to a focussed thing
> which does not appear focussed.
>
> cheers,
> _mallory
>
>