- tabindex=0 doesn’t affect ordering, does it?
- why do you need to listen for events at the document level?
not that i disagree with the article, but some arguments didn’t seem right.
replies(2):
- why do you need to listen for events at the document level?
not that i disagree with the article, but some arguments didn’t seem right.
Of course it does. tabindex=0 doesn't sort naturally into the automatic tabindex order, it sorts AFTER everything. So you are jumping through all the other tabindex elements, then you are jumping back to all tabindex=0.
It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
Yes, but often you have elements with taborder > 0.
> It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.
Only if document order is sane. Usually with modern websites it isn't, document order is a broken notion if you can position elements at will and e.g. put navigation at the bottom of a document but move it to the top by CSS. Which is actually a recommendation that some people make for acessibility...
What you usually want to do is assign a sensible taborder > 0 to the one form element that the user is probably currently using. Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
You can just as easily apply the same tabindex to a div though.
> Only if document order is sane. Usually with modern websites it isn't...
Well that's the real problem, all your non-interactive content (like text) is going to be out of order too. You're just adding to the confusion if buttons and other inputs are in a different order from the content they're associated with.
> Otherwise, he will pointlessly tab through search, menus, cookie bars and a ton of other pointless stuff first.
The proper way of dealing with this is a "Skip to Main Content" element:
No, it isn't the proper way. That only works if you can see the skip link and know to press enter. Otherwise you will tab straight into the navigation. So possibly useful for screen readers, but completely useless for most keyboard users. Yet another stupid webdev workaround for a selfimposed problem.
What you should do is autofocus the first form element (if there is a form), give it tabindex=1 and number the other form elements in a sensible ascending tabindex order. Otherwise, proper semantic markup is sufficient, even for screen readers.
And yes, this is an acceptable solution according to the W3C:
https://www.w3.org/WAI/WCAG21/Techniques/general/G1
Your solution of focusing the first form element is pretty idiosyncratic. It's better to follow WAI patterns, because patterns have predictable behavior. Otherwise, keyboard users will have to learn how to interact with your website from scratch, instead of just following the same pattern they're used to from other sites.
Your original comment was to use tabindex to skip search, menu bars, breadcrumbs, etc. and for that there are better options.
I can imagine screen readers would deal particularly poorly with this behaviour, because the user would be dropped in a field without any of the context of the page, just the field label to work with. However, I've not been able to test that out properly.
I don't think the behaviour you're describing is anywhere near as common as you think it is, and I suspect it would make a page less accessible for a number of kinds of users.