tab jumps are weird

[otacke]

It seems there might a problem with the tabindex. I have not really looked into this topic (related to ARIA), but it seems that the jump order for n alternatives is:

• 1st alternative
• 1s_ hint
• 2nd hint
• 3rd hint
• ...
• n-1th hint
• nth alternative
• nth hint

Looks strange to me.

[falcon-git]

You are right. With hints/tips it doesn't seem to work exactly as designed. Arrow keys to move the focus between alternatives is intended, tab to focus on the hint is also as designed. If you tab several times you move between hints, also as designed afaik. The last alternative gets the focus after the last hint, this is not as designed afaik.

[otacke]

Oh, now I get it. I still have to learn about how to design accessible applications.

I had assumed that the tab key was the major key that should be used to jump from element to element which here are the alternatives. But it makes total sense to give focus to all the alternatives first and then choose the sub elements with the arrow keys. I guess since the role for the container says "radiogroup", people will know that they can now use the arrow keys for selection?

[falcon-git]

Yes, that is my understanding. The default behavior of normal radio button groups is that you use keys to select and tab will make you move along.

[icc]

Regarding the hints, I wonder if it would make more sense if you could only tab to the hint next to the focused option. It is essentially a list where you can possibly have an "infinite" number of tabbable buttons, which I believe is to be avoided according to ARIA.