Hello

At the moment I don't know, how to include the buttons into the taborder, because the buttons are optional. Without JavaScript, the buttons does not exist. With disabled BB-code-features all or specific buttons does not exist.

In posting.js#L538, the tabIndex attribute is defined (always -1). Most of the attributes of a button are defined by the variable obj such as obj.code. I think it is quite easy add a further attribute to obj, e.g. in posting.js#L433 and posting.js#L484. We just have to figure out a reliable starting value.

I read a bit about tabindex and have found statements that say that numbering is a bad idea (for example the first reply in this Stack Overflow thread) because of its bad maintainability. One has to recheck the order with every structure change. And I encountered exactly this (the result of missing order checks) in the posting form. The order of focusable elements (links, input fields, textarea(s) and buttons) is completely mixed up.

You start tabbing in the page head, jump through the search form to the subnavigation item (in case of a reply "back to entry of Someone") and the next jump (for a logged in user) goes to the "Attach signature" checkbox and not (what I expected) to the input field for the subject. From there it goes to "E-mail notification ..." and from there to the "To top" link in the page footer. After the jumps through the footer links one lands in the browser tab bar. From there it goes through the elements of the browser UI over the browsers bookmark bar (if activated) to the input field for the subject and the textarea for the message itself ommiting the tags input (if available). From the textarea it jumps to the submit and preview buttons and then back to the main page link in the page header. That's terrible, to say the least.

Reading the MDN page for tabindex, it seems to be clear, what happens.

Two quotes from there:

Some focusable HTML elements have a default tabindex value of 0 set under the hood by the user agent.

A positive value means the element should be focusable in sequential keyboard navigation, with its order defined by the value of the number. That is, tabindex="4" is focused before tabindex="5" and tabindex="0", but after tabindex="3".

Emphasis by me

This means, that a browser follows the natural order as long as it finds no tabindex, given with a positive number, follows then the given order of positive values in ascending order when it focussed the first one and then jumps back to the elements with implicit (no tabindex attribute) or explicit set tabindex value of 0 afterwards. It possibly follows another group of tabindex with positive values if it finds another group.

My conclusion: With exclusively no tabindex (implicit value 0 for focusable elements) in links and forms the browser would simply tab through the elements in order of appearance. Elements, that shoudn't be focusable with tabbing (for whatever reason) should get a tabindex with a negative value (we use the common -1 for this). Keeping the tabbing system with positive values, an order with gaps between the values (1, 2, 3, 4, 5, 10, 11, 12, 20, 21, 28 and so on) shouldn't be a problem. But!: The order must be plausible for the users. The current state is it absolutely not.

The simpler and more maintainable system is IMHO to not set a tabindex order (with exception of a negative value for elements, that shouldn't be focusable when tabbing).

I didn't find a method to make a button group behave like a radio button group (tabbing to the group with [TAB] and stepping through the group with [Space]) (that was the initial question of Emanuel).

Tschö, Auge