E-mail List Archives
Re: Tab Order and Focus Question
From: Guy Hickling
Date: Mar 15, 2019 6:52PM
- Next message: Birkir R. Gunnarsson: "Re: Is NVDA using the wrong type of widget (tree) to show the headings on a page?"
- Previous message: glen walker: "Re: Is NVDA using the wrong type of widget (tree) to show the headings on a page?"
- Next message in Thread: glen walker: "Re: Tab Order and Focus Question"
- Previous message in Thread: glen walker: "Re: Tab Order and Focus Question"
- View all messages in this Thread
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
- Next message: Birkir R. Gunnarsson: "Re: Is NVDA using the wrong type of widget (tree) to show the headings on a page?"
- Previous message: glen walker: "Re: Is NVDA using the wrong type of widget (tree) to show the headings on a page?"
- Next message in Thread: glen walker: "Re: Tab Order and Focus Question"
- Previous message in Thread: glen walker: "Re: Tab Order and Focus Question"
- View all messages in this Thread