[thyristan]

> - tabindex=0 doesn’t affect ordering, does it?

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.

[pverheggen]

That's the same behavior as a <button> without tabindex, like the author is proposing.

It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.

[thyristan]

> That's the same behavior as a <button> without tabindex, like the author is proposing.

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.

[MrJohz]

You almost certainly don't want to assign tab order manually. Theoretically, if your html is out-of-order for some reason, then you can fix it with taborder, but there are so many issues with out-of-order html that it's much better to avoid that in the first place. Even on modern websites, it is almost always easier to lay your html out in the correct order rather than messing around with the order via CSS. (I read an article recently by a web accessibility expert that discussed the issue of flexbox's order parameter and how the working group designing it failed to accessibility into account when adding it to the spec: https://alice.boxhall.au/articles/a-threat-model-for-accessi...)

You mention using it to skip a nav header or something similar, but (1) you have autofocus for that if you need it (and you don't usually need it), and (2) the pattern where you provide a "jump to content" button is typically a better approach, because it allows the user to decide what they want to do when they arrive on your site, rather than you deciding for them. If the "jump to content" button behind visible when focused and is the first element on the screen, then it works perfectly for screen readers and other keyboard users, and you don't need to handle taborder manually.

There are always exceptions to these sorts of rules, and some times tabindex might be necessary, but I've not yet come across a case where the problem couldn't be solved better in a different way.

[pverheggen]

> Yes, but often you have elements with taborder > 0.

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:

https://webaim.org/techniques/skipnav/

[thyristan]

> The proper way of dealing with this is a "Skip to Main Content" element: > > https://webaim.org/techniques/skipnav/

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.

[pverheggen]

Usually you would have it appear when it's focused, like this for example:

https://www.nytimes.com/

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.

[thyristan]

Any website implementing a form for data entry is expected by any sane user to autofocus the first form element.

[bugsliker]

I'm saying tabindex=0 is naturally sorted wrt other naturally focusable elements. That matches the behavior of the <button> you're trying to emulate. I don't know what tabindex>0 has to do with this.

See this fiddle https://jsfiddle.net/483uqjnp/

(again, I do not condone building your own <button>, just pointing this out)

[brandonhorst]

This is incorrect. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[thyristan]

That is correct. From your link: "tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source. "

[Ma8ee]

Your link actually supports the comment you replied to.

[minitech]

tabindex=0 does sort naturally into the automatic tabindex order.

> So you are jumping through all the other tabindex elements

This part is correct (for elements with an explicit positive tabindex), which is why specifying an explicit positive tabindex is considered a code smell. If you don’t specify a tabindex on an element that’s focusable by default, it behaves like tabindex=0.

Try it:

  data:text/html,<button>foo</button><i tabindex=0>bar</i><button>baz</button>