Reordered sequential navigation

[wicg]

Reordered sequential navigation

[Nadya678]

Any equivalent for focusing the HTML object and/or to make it tabbable is needed. I use in many html5 projects tabindex="-1" on span to make the element focusable by mouse/touch and tabindex="0" to make te element tabbable. There are specialized controls made from <span/>, <input/> and <label/> elements. Part of these projects are commercial and they validate on W3C.org including html5 and css3.

Because users (my clients) need select/option field fully styled (including dropdown arrow and list), I also made equivalent with use of <span/>, <input/> and <label/> elements. The dropdown works via :focus on span (tabindex="-1"). There is no tab-index="0" because the used are tabbable. This control works with touch/mouse and keyboard without any JS.

I read the attribute "tabindex" will be removed from html5 (probably without changing DOCTYPE declaration- why?) It is in use.

In new specification (if tabindex will be removed - WITHOUT DEPRECATION - YES, tabindex is not deprecated now), there is needed new CSS style.

Because in CSS is possible absolute positioning and fixed positioning, there will be needed also positive values of tab-index/nav-index according to w3c/csswg-drafts#1748. Probably also nav-group due to discussions. Other proposed solution for the problem (in other threads) are often buggy for absolute-positioned elements and for fixed positioned elements.

There is also needed "nav-index: none;" if a "modal" "window" (a <section/>, <aside/>, <form/> or </div> only looking like dialog window) will be shown for example with any form.
user-select:none; still lock only clicks but no keyboard navigation. There is many questions on stack overflow to this problem. Not solved. I patially solved this problem for radio+label and checkbox+label fields and for <a><span/></a> sequence with manipulation of visibility but no solution for TextBox and <textarea/>. The solution is hard but shall be easy to use... (additionally in last example - without internal <span/>).

BTW: my clients won't understand, the <select/> cannot be fully styled and they need... solution for this problem with change ONLY FRONT-END. If html5 attribute tabindex for <span/> will be removed, I have no solution for them for the moment.

[SebastianZ]

@Nadya678 I'm not sure where you read that the tabindex HTML attribute would be deprecated. tabindex can't be removed, because that would break the Web.

What was discussed in the threads linked here was a possible nav-index CSS property in addition to the HTML attribute tabindex.

Sebastian

[patrickhlauke]

for avoidance of doubt, worth noting: the problem is not just about focusable elements (moving focus with the tab key). this also affects overall reading order when using assistive technologies (e.g. using a screen reader, using reading keys to consumer the content of the document). not something that can just be patched with tabindex or whatever, but rather a fundamental problem of how the content is exposed in a linear fashion to AT.

[frivoal]

Issue migrated to w3c/csswg-drafts#3377