Please add "tab-index" to CSS specification #1748
Comments
|
Default value: |
|
I agree that there is a need for controling the tabing order. As you said, layout can change the visual order of things. Often, it is still better to keep the tab order in the logical document order, but sometimes it is useful to reorder. Since it depends on layout, I agree it should be done in css. However, I don't think But that doesn't mean we don't need a solution. We do. An alternative has been discussed, but not yet specified: This also allows you to reorder elements for tab navigation, but instead of needing to figure out a global order in your page, you can simply change the order locally. Specifying this is in my todo list. It is used differently than I understand it may be a little hard to evaluate without a full specification, but if you understand the idea, I'd appreciate your feedback about whether this seems like it would solve your use case, or whether you think it would have issues. |
|
Browsers correctly recognize The tab-index is supported by all browsers identically except of firefox for input[type="radio"] if all are unchecked. Firefox tabs via all unchecked radio's, other browsers tabs only via first of group. Thus this behaviour is the easiest to implement. My description can be updated by other users. I poorly speak english. Nav-pre, nav-next (if there will be identifiers) can make infinite loop and trigger developers to "id-itis" ("id"-like div-itis/class-itis). BTW. I tkink, the tab-index will by used mainly for elements with set "tabindex" property and form controls. In this purpose, here is a little elements for styling and developer for each skin (layout) can define it if it is possible. If other solution is better, it also can be implemented instead this, but Opera (Presto, before WebKit) has implemented this algorithm (except "none"). Currently tab order in many layouts is chaotic and there is possible to access controls that should by inaccessible. It is more needed than pointer-events. Disabling of elements (for mouse and touch only) can be reached via negative z-index and additional layer (via ::after or ::before) on other element. Does nav-pre/next is able to disable any element from tab-queue? Regarding |
|
I think For example, there are button elements like: <button id="b1">Button 1</button>
<button id="b2">Button 2</button>
<button id="b3">Button 3</button>
<button id="b4">Button 4</button>
<button id="b5">Button 5</button>if the tabing order is specified with nav-index, it will be: button {
position: absolute;
}
button#b1 {
top: 20%; left: 25%;
nav-index: 1;
}
button#b2 {
top: 30%; left: 0%;
nav-index: 2;
}
button#b3 {
top: 50%; left: 40%;
nav-index: 3;
}
button#b4 {
top: 60%; left: 25%;
nav-index: 4;
}
button#b5 {
top: 70%; left: 20%;
nav-index: 5;
}otherwise, the same result using button {
position: absolute;
}
button#b1 {
top: 20%; left: 25%;
nav-next: #b2;
}
button#b2 {
top: 30%; left: 0%;
nav-prev: #b1;
nav-next: #b3;
}
button#b3 {
top: 50%; left: 40%;
nav-prev: #b2;
nav-next: #b4;
}
button#b4 {
top: 60%; left: 25%;
nav-prev: #b3;
nav-next: #b5;
}
button#b5 {
top: 70%; left: 20%;
nav-prev: #b4;
}If I want to add a new button element(
I think we can just give the direction to find the previous or the next element to |
|
@jihyerish Your example can be handled without defining any order, as the default order is how the elements appear in the DOM. So, a better example is when you want to toggle through them in a different order. E.g. let's say we want the order to be button#b1 {
nav-index: 1;
}
button#b2 {
nav-index: 4;
}
button#b3 {
nav-index: 2;
}
button#b4 {
nav-index: 5;
}
button#b5 {
nav-index: 3;
}vs. button#b1 {
nav-next: #b3;
}
button#b2 {
nav-pre: #b5;
nav-next: #b4;
}
button#b3 {
nav-pre: #b1;
nav-next: #b5;
}
button#b4 {
nav-pre: #b2;
}
button#b5 {
nav-pre: #b3;
nav-next: #b2;
}
That's probably the biggest disadvantage of having an absolute index property. One big advantage is that it corresponds to the
As it probably doesn't make sense to specify two different navigation paths for forward and backward, I think only button#b1 {
nav-next: #b3;
}
button#b2 {
nav-next: #b4;
}
button#b3 {
nav-next: #b5;
}
button#b5 {
nav-next: #b2;
}And the backward navigation is automatically inferred from the forward navigation.
In my opinion, navigation should initially have specified that way, i.e. regarding the visual placement of the element for the default navigation order. Your idea sounds quite interesting, though I'm not sure whether that's feasible. It requires people to calculate the angle between the elements to get the right order. What if there's no element in that direction? In regard of my previous sentence, what about introducing a property that allows to specify a visual navigation order? E.g.: nav-order: strutural | visual;With Having said that, this might be introduced additionally to any explicit way to set a navigation index. Sebastian |
It cannot be modified via nav-pre and nav-next without addition of identifiers (modify of markup). ray() is also bad for scrolled pages with fixed-positioned elements. the ray() can be resolved differently in this case due to scrollbar position. It also cannot be resolved if width of site isn't constant and part of elements is displayed as inline-table or inline-block (or inline for non-replaced elements with tabindex set to equal or greater than 0). The nav-index/tab-index hasn't these problems. I always starting coding of page write the markup (HTML) for the page SEMANTICALLY. Next Iwant to use CSS (and only CSS if it is possible). Next step: required JS if client needs to reload fragment of page etc.). I like to use ::after, ::before, advanced CSS. I'm annoying when I must change markup (and thus part of CSS) to add additional ID's, For example we have WordPress, Drupal AUTOUPDATED page, we want only use CSS to change visual effects. These visual effects result in chaotic tabbing. What is the best solution? We have not ID on all controls. the ray() is in part of layouts not constant (fixed-positioned elements). |
|
Regarding Part of elements after displaying static "dialog" box shall be disabled via other mechanism. tab-index=-1 do it currently. Btw. I don't want to calculate degrees (rays). Is here possibility for nav-top/nav-bottom etc set full selector, not only ID selector? Handling 4 arrow in CSS has sense. BTW. For the moment none browser is able to detect if backface-visibility is hidden and object rotated more than 90deg and invisible. TAB key still works on hidden elements (except if visibility is set to hidden). The backface-visibility has no sense I still must add in transitions "animation" for visibility and thus... I can remove backface-visibility. |
|
I agree that needing to add IDs to everything I want to change the tab order on would be a gigantic pain. I almost might as well add tabindex attributes, if I have to change markup anyway. I would consider this a non-starter.
That could mostly be taken care of with a reset, like this: input, a, select, textarea, button, iframe { tab-index: 100; } Which would be way easier than the current situation with tabindex attributes. But even so, it is not ideal for when you wanted to change the order within one limited area, without having to type in numbers for everything after that. It would be better, if we could isolate a group of elements to set tab order on. Something like this, maybe: fieldset { tab-index-group: isolate; } The result of that would be that the tab-index values would only affect elements within that container. PS: even if it was only being able to set tab-index 0 and -1 values via CSS, that would be huge by themselves. And having a 'none' value would also be cool, if it was like 'pointer-events:none', but also would stop propagation of focusing to items below it in the z direction. |
|
I've split out my idea for a property influencing the default navigation order to #1764, so it can be discussed separately. The tab group is a good idea to limit the indexes to a part of the element structure. It mitigates @jihyerish's issue about having to change the index of all following elements when inserting an element in between. It is still an issue for bigger groups, though. Another idea would be to combine both, relative and absolute indexing in one property. The syntax for that could then look like this: nav-index: <integer> | after(<complex-selector>)Allowing complex selectors instead of only ID selectors also provides more flexibility and doesn't require to add IDs to the elements. Sebastian |
|
One more point, can we agree on Sebastian |
|
tab-index-group:isolate is not a good because I don't want to prevent TAB stops on the browser gui elements. Isolating may be annoying for users without mouse and without touch screen. I currently set visibility hidden for input type radio and checkbox. For "a" elements I style ::before and ::after and hide "a". This prevent tab stops for check boxes (still visible label) and "a" (stil visible before or span for IE) but... the text-box and password and textarea doesn't accept ::before and additionally visibility:hidden will hide text. I only can simulate
how to find element that shall be focused with shift+tab key? |
Thanks, @SebastianZ ! It's better. : )
Yes, it's tricky for selecting the element to focus. Maybe if there is no element in that direction, then the closest element from the ray can be focused.
The
Completely agree with you. 👍 |
|
On Tue, 2017-08-22 at 03:27 -0700, Nadya678 wrote:
[...]
The CSS including floating, position absolute, fixed and relative can
change the visual order of elements, The developer shall have a tool
to set appropriate TAB order for all elements.
Won't this be really confusing for someone using a text reader, e.g.
someone blind? the DOM order isn't changed, and that's what the text
reader will use. So the right thing isn't to change the tab order to be
different from the document order, perhaps, but to tell the browser
that the document order has (in a sense) changed. What do you think?
Liam
…--
Liam Quin, W3C, http://www.w3.org/People/Quin/
Staff contact for Verifiable Claims WG, XQuery WG
Web slave for http://www.fromoldbooks.org/
|
|
For me the nav-index or tab-index or navigation-index is no problem. For the moment no browser support it. Last versions of Presto supported nav-index to "manipulate" tabindex attribute. Thus I sugested the tab-index with hyphen (like attribute name, some people write "tabIndex" for the attribute) or nav-index - implemented in last versions of Presto (Opera version 11.5-12.0). But... tabindex attribute support is shortened to define actions with TAB or SHIFT-TAB key. What browser supports other heys with use of tabindex? |
|
If you want to test out what using a The plugin works as intended, but after actually trying out the functionality in browsers, seeing what it does and how browsers handle Setting The only use case I could think of where it might be a help is in the case where you have re-ordered items using flexbox (which you shouldn't do…) and want to 'repair' a more natural Problems
VideoCode<section>
<input placeholder=first>
<input placeholder=second>
<input placeholder=third>
</section>
<style>
input {
display: block;
width: 33.33%;
float: left;
font-size: 14pt;
padding: .5em;
}
[placeholder=first] {
--tab-index: 3;
}
[placeholder=second] {
--tab-index: 2;
}
[placeholder=third] {
--tab-index: 1;
}
@media (min-width: 600px) {
body {
background: tan;
}
[placeholder=first] {
--tab-index: 2;
}
[placeholder=second] {
--tab-index: 1;
}
[placeholder=third] {
--tab-index: 3;
}
}
@media (min-width: 1200px) {
body {
background: pink;
}
[placeholder=first] {
--tab-index: 3;
}
[placeholder=second] {
--tab-index: 1;
}
[placeholder=third] {
--tab-index: 2;
}
}
</style>
<script>
/*
# Tabby
## version 0.0.1
Author: Tommy Hodgins
License: MIT
*/
const tabby = {}
tabby.load = () => {
tabby.findRules()
}
tabby.findRules = () => {
// For each stylesheet
Array.from(document.styleSheets, sheet => {
// For each rule
sheet.cssRules && Array.from(sheet.cssRules, rule => {
tabby.process(rule)
})
})
}
tabby.process = rule => {
// If rule is a qualified rule, process it
if (rule.type === 1) {
let node = tabby.transform(rule)
document.querySelector(node.tag).setAttribute('tabindex', node.value)
}
// If rule is an at-rule, find all qualified rules inside
if (rule.type === 4) {
// Remember media query text
let mediaText = rule.media.mediaText
// If there are qualified rules, find all rules
rule.cssRules && Array.from(rule.cssRules, mediaRule => {
let node = tabby.transform(mediaRule)
if (window.matchMedia(mediaText).matches) {
document.querySelector(node.tag).setAttribute('tabindex', node.value)
}
})
}
}
tabby.transform = rule => {
let selector = rule.selectorText.replace(/(.*)\s{/gi, '$1')
let ruleText = rule.cssText.replace(/.*\{(.*)\}/gi, '$1')
// For each rule, search for `--tab-index`
let index = ruleText.replace(/(--tab-index:\s*)(\d*)(\s*\!important)*\s*(?:;|\})/i, (string, property, value, important) => {
return parseInt(value)
})
return {"tag": selector, "value": index}
}
// Update every `load`, `resize`, `input`, and `click`
window.addEventListener('load', tabby.load)
window.addEventListener('resize', tabby.load)
window.addEventListener('input', tabby.load)
window.addEventListener('click', tabby.load)
</script> |
Yes. It is useful. The most useful values are tabindex="0" for example on The tabindex="none" (currently not defined) will able used to make "disabled" visual/behaviour effect for input, area, select etc. Disabled vithout disabling them from sending via http. Thank you for JS but I want NOT to use JS to change navigation behaviour if I need "modal" dialog window with a form. Here is needed CSS equivalent. |
|
@Nadya678 I didn't mean that So suppose you had tab-index: 0 for every tabbable element outside the group, and 3, 2, and 1 respectively for the values inside the group. You would tab into the group in DOM order, but the first one in the group to tab to would be the one with tab-index:1. |
|
You could also have an index on the group element itself, not to cause the grouping box to receive focus, but to set the where in the tabbing order the descendants of the box fall in relation to items outside that box. This would give the author a lot of power to control the tabbing at micro and macro levels. For instance: The order would be a, e, d, b, c |
|
Almost like the inputs inside of the tab-index:1 box are tab-index 1/1 and 1/0. |
|
The more appropriate tab order in this case will be: ("tab-" may by changed to "nav-"). It will be still compatible with tabindex in HTML. |
|
Ugh. Yeah, I forgot 0 comes after all the positive numbers when using tabindex. It is so unintuitive, but I agree that diverging would probably be worse. I don't have a problem with nav-index or tab-index as names. I prefer tab-index because it makes it easier to understand as a corollary of the attribute. IMO, |
|
Summary of discussion about tab-index/nav-index, tab-index-group, nav-up, nav-left, nav-top, nav-right. Please remember, the TAB key is the the most important way for navigation, the nav-up etc. is only auxiliary way (works for the moment only for radiobutton gruop and option in select?) The default values: Specification: tab-index-group: enclose elements in tab group. tab-groups are arranged in non descending behaviour. An example (with inline styles for easier understanding): translated to group/index: Tab-order (ascending): Navigation with arrows: Note: here can be recognized (by nav-up, nav-down, nav-left, nav-right) only elements with tab-index other than none. Behaviour of detection: * last and first: if any selector inside current element meet the selector the "first" and "last" words points it. If no element inside current element meets the definition, the words mean "first inside document" and "last inside document". Option parent: the CSS set is calculated via currentElement.parentNode.querySelectorAll(selector) instead of document.querySelectorAll(selector). If selector contains "\" or double quote - it shall be escaped via back-slash (0x5C) character.
default value: if RTL reading is set the behaviour for nav-right and nav-left are swapped (words: after and before shall be swapped). Does it have a sense? Can we ask Google, Mozilla and Microsoft developers what problem they see and how many work it needs? If tab-index-group is really needed, I propose "tab-group" name for it. It is shorter. |
|
I think it's better to discuss about |
As I indicated earlier, it is implied by the forward order. So, in the case of the
Yes. I'm open for better names.
Very good point! It's an important point to think of vision impaired people in regard of this feature.
How would you do that? When talking about the "visual order" for the navigation path, I see two solutions for screen readers:
Having said that, I wonder if screen readers currently interpret the Of course, this also applies to the Sebastian |
|
complex-selector only for "up, left, right, down". For nav-index/tab-index there are no complex-selector. It is equivalent of HTML tabindex attribute with additional "none" (non-focusable). Thus Shift+tab is no problem. nav-order - is it needed if tab-index/nav-index (and tab-index-group) will be implemented? How should work "Visual" for fixed positioned elements? If it will be implemented, the one medium shall be "screen/tv". Yes, screen readers interpret the tabindex including "-1". Thus the tab-index / nav-index shall be easy to implement. |
|
On Aug 31, 2017 4:17 PM, "Sebastian Zartner" <notifications@github.com>
wrote
[snip]
When talking about the "visual order" for the navigation path, I see two
solutions for screen readers:
1. Use the DOM order.
2. Follow the layout algorithm and also use the visual order.
Having said that, I wonder if screen readers currently interpret the
tabindex HTML attribute.
Sebastian
Can you explain what you mean by that? As in screen readers 'interpreting'
tabindex?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1748 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA1IZdfyLZv9nYJhjVB_hvCCLVaO9YQ3ks5sdxS8gaJpZM4O-a53>
.
|
I don't get your reason why you are against a selector for the
Yes,
I never used a screen reader. So, I am wondering how they read a page. Do they read the whole page at once? And if so, do they consider the Sebastian |
For what it's worth, this behavior is available today if you're using Shadow DOM. Here's an example (need to view it in Chrome): https://jsbin.com/lidaguf/edit?html,output
Generally speaking, screen readers navigate the page in DOM order. Think of it kind of like linearly going from element to element. Just navigating with the Tab key would not be useful because that would only move between interactive controls, so a screen reader user would miss all the other content on the page. My very rough understanding is when a user lands on an unfamiliar page they will typically use a shortcut to navigate by headings (h1-h6 tags). When they find an interesting heading, they will then drill into that section, navigating in a linear fashion, going element by element or line by line.
A user could press the tab key to jump to the next interactive element, but if they're just browsing through text content they'd be doing so in DOM order. |
|
Based on the CSS-WG having decided to push this general topic to WICG (see meeting minutes), I'm closing this issue in favor of WICG/spatial-navigation#10. To be clear, this is not meant to be a rejection of what has been discussed here, only moving the discussion to a group that is tailored for this problem space and to which the CSSWG has decided to move the discussion to. This specific thread has been documented in the wiki page dedicated to collecting discussions on this topic. |
The needed specification:
tab-index: <numeric-signed> | none | inherit | unset;If -1 or lower, the element is focusable by mouse/touch but not TAB key.
If 0, the element has default tab order and is focusable by mouse/touch.
If greater than 0, the number precise order in tab queue due to ascending values.
if "none" the element is not focusable by keyboard and not focusable via touch/mouse.
Reason:
The CSS including floating, position absolute, fixed and relative can change the visual order of elements, The developer shall have a tool to set appropriate TAB order for all elements. Additionally if any "modal" dialog "window" will be shown via CSS (it is possible!), here shall be possibility to disable tab-index (via "-1" value) in the background without changes in markup (HTML).
If it is needed, I can send my private (commercial) solutions for "modal" dialog "windows" that are using only HTML5 and CSS without any scripts. It is real requirement.
On the Stack Overflow you also can find questions how to disable element via CSS or how to change tabindex by CSS only.
BTW. Opera from 11.5 to 12 implemented this style as nav-index partially. Thus the name may also be: nav-index instead of tab-index.
Redirected from html thread: whatwg/html#2953
The text was updated successfully, but these errors were encountered: