[css-nav-1] Reordered sequential navigation

[frivoal]

---

Migrated from WICG/spatial-navigation#10
Originally created by @frivoal on Wed, 15 Nov 2017 05:23:00 GMT

---

There is a recurrent complain coming form a11y people that sequential navigation (aka moving focus with the tab key) as it is today is not adequate for all use cases / all users, especially in the face of increasingly powerful tools in CSS to lay things out with relatively little connection with the document order.

This has led to suggestions that sequential navigation should follow the order property in flexbox, or that it should follow "the visual order", or to the suggestion that there should be a nav-index property, or that there should be a nav-next property, or a nav-order property, or a combination of the previous things with some mechanism to scope it to a DOM sub-tree.

There are multiple difficulties with that:

• While the DOM tree has a natural order, a visually laid out document does not. It is in 2D, which has no inherent ordering, and on top of this color, contrast, size, movement, and more come to influence in what order things are typically perceived. This makes it far from trivial in the general case to find a linear order which could be described as "the visual order". This makes it neither easy to define an order the browser should go through, nor to find the right set of properties that authors could use to express it.

• There seem to be multiple overlapping and conflicting requirements. Sighted mouse users who occasionally use the keyboard as a supplemental navigation aid expect different things form sighted people who primarily navigate by the keyboard, who in turn expect different things from blind or partially blind users who primarily navigate the document based on its logical structure.

Discussions in the CSS-WG and in the WICG meeting leading to the creation of this repo have generally agreed that at least some of the cases that had previously been expressed as a desire for reordered sequential navigation would probably be better server by spatial navigation. The general consensus is that a good way forward is to first focus on getting spatial navigation to work, then look for use cases that are still not adequately covered by the combination of (non-reordered) sequential navigation and spatial navigation.

To be most useful, such use cases should document:

1. How the document is marked up
2. How the document is laid out
3. What class of users or what usage scenario is still not well served neither by sequential navigation nor by spatial navigation.

I have created a wiki page to document these use cases. Contributions most welcome.

Also, since this has been a long running topic, linking to (and summarizing) previous conversations would probably be useful. There's a wiki page for that too.

I would like to encourage people interested in this issue in contributing to the two wiki pages above. With that information, and once we've made enough progress on spatial navigation (See the rest of this repository for this broader topic), it will be much easier to return to this topic and see what is left to solve.

[frivoal]

---

Migrated from WICG/spatial-navigation#10 (comment)
Originally created by @patrickhlauke on Thu, 22 Feb 2018 19:31:14 GMT

---

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]

---

Migrated from WICG/spatial-navigation#10 (comment)
Originally created by @SebastianZ on Mon, 27 Nov 2017 21:44:22 GMT

---

@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

[frivoal]

---

Migrated from WICG/spatial-navigation#10 (comment)
Originally created by @Nadya678 on Sun, 26 Nov 2017 23:42:41 GMT

---

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 #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.

[bkardell]

It seems like an overstatement to say that 2D has no inherent order, quite a lot of it does. When you get a 2d thing to read, unless there is a real design problem you shouldn't be looking at it and thinking "these things have no relationship and I can read every bit in any order equally well. Many of the reasons that we have many of the concepts that we do come stem from that observation. As @patrickhlauke says, it isn't just 'focus navigation' that that applies to.

Focus is especially tricky though and I think this get especially interesting as we reshape interfaces and order isn't critically important... Kind of like the difference between a list and an unordered list. Imagine a gallery of images, which are links and have some brief text associated with them. Each has different aspect ratios and sizes and the author is more concerned with balancing aesthetics than, for example, when they were posted. Depending on the user's screen size, the best "fits" can change - perhaps on a nice big screen we get 15 'rows' and 3 'columns' with a few images 'spanning'... but as things scale down, something a further down moves 'up' in the order to better fit. If that's the case, and you are only using a reader it might be fine that those don't actually match actually - but, today, this would leave a strange gap where keyboard users experience something that clearly does not match the 'expected' order. A tab press on the second image might 'jump' the user to what they perceive as the 25th image, and the next to the 5th, and so on.

I feel like at a minimum, the 'order isn't critically important' case isn't actually that rare in responsive design and could be better addressed.

[frivoal]

It seems like an overstatement to say that 2D has no inherent order, quite a lot of it does.

I know, and I am saying that there isn't in an intentionally provocative statement. In a document-like thing, you tend to have a pretty strong order nonetheless. In an an app-like thing, it's a lot less clear. Local areas tend to be ordered, but at the top level less so. Is the toolbar before the side panel? ¯\_(ツ)_/¯

So, while I do agree my statement is too strong, I do think that assuming "The visual order" is a thing on par with "The document order" is misleading. And since we're so used to the document order, a bit of a provocative statement seems constructive.

That said, I think you have a point saying that in many case, trouble comes from the fact that there are many cases where even though the document order exists, it isn't particularly meaningful, so authors tend to feel free to place things visually with little regards for the document order, and navigation ends up being erratic.

In general, I think things like flexbox and grid etc should continue to follow document order when dealing with sequential navigation, as there are many cases where document order is meaningful. But thinking of it, maybe there should be something in the markup to indicate "the descendants of this element are not strongly ordered semantically", in which case sequential navigation should be informed by the visual placement of things more than by document order.

If this switch should exist, I feel quite strongly that its proper place is in markup, not in css.

[jimmyfrasche]

(This is probably the wrong place to put this but I'm replying to posts in this thread about reading order and 2D order).

Right now we have the dom order, the reading order, the tab order, and the visual order.

Ignoring tabindex, the dom order = the reading order = the tab order (for some sufficiently permissive definition of equality) but the visual order is essentially decoupled from these by CSS.

The reading order and the tab order can be affected by CSS with display: none but that only removes subtress from the reading and tab orders—it does not allow them to be permuted.

The end result is that there are these neat things I can do visually with CSS that I cannot do when taking accessibility into account (which should be always) because the reading and tab orders remain unchanged and fall out of sync with the visual order. Grid and flexbox allow a lot of cool, easy layouts but the dom order remains a hard constraint on what can be done. Generally, reading and tab order should follow dom order, but a sensible escape hatch would be a great enabler.

From what I can tell, css-nav-1 allows the focus order to be extended to 2d based on visual distance and spatial navigation containers. This is very cool and useful, but does not seem to affect the reading order.

Reading up on the issues that led to this draft, I saw a lot of calls to control the tab order in CSS, either explicitly or to follow ordering changes by, say, flexbox. That would allow reordering things visually while maintaining a natural tab order, but the reading order would still fall out of sync and skip around unnaturally.

Generally, I think it's good to keep the tab order bound to the reading order. Those go together naturally. If two buttons are right next to each other in the reading order they should be next to each other in the tab order and logically next to each other in the visual order.

While the reading order and, barring css-nav-1, the tab order are linear in nature, even without any CSS they are still laid out in 2d based on the dimensions of the language by chunking it into strips in the inline dimension that are stacked in the block dimension. I'm going to stick with top to bottom, left to right from now on, because it's the only one that I'm sufficiently familiar with. This defines an approximate lexicographical order where, for English at least, something in the top left is before something in the bottom right, but this could be cultural bias on my part that does not generalize. Regardless, I don't think this alone is sufficient to define an order since layouts are really 3d and you can have non-statically positioned elements floating about or even just 2d layouts that fit together in visually clear ways that would be hard to determine programatically.

Using CSS to create layouts lets you rearrange items into new layout orders, like putting a sidebar next to the main content or displaying a list of images in a grid, but inside those placed elements things still follow the language's visual dimensions. If you do this in a way that does not contradict the dom order and the language's dimensions, everything continues to work as expected. If I have a list of linked images using an implicit grid keeps the reading and tab orders top-to-bottom, left-to-right. The visual, reading, and tab order all remain natural and in accord with the language order. But if I use flexbox to show them in reverse, the reading and tab order become the opposite of the visual order.

If there were a way to control the reading order independent of the dom order, there would be more latitude to arrange things visually, which would be handy for fitting everything into differently sized viewports. As long as the tab order remains bound to the reading order and the changes to the reading order reflect the visual order of the layout everything works out.

Since the reading order is linear and the layout is 2d this would be some kind of projection declaring stuff like "the header goes first, then the main content, then the sidebar, then the footer" irrespective of their dom order and within those items reading and tab order follow as normal, excepting additional overrides.

I'm not sure how that would or should be specified in CSS, but it seems like it could be very similar to (but simpler than) flexbox: define a "reading container" and set the relative or absolute "reading order" of its items. That would only allow you to permute adjacent elements, but that seems sufficient and more complicated cases would get quite complicated. It's possible that there are a lot of things I'm not taking into account, though. One thing this still wouldn't let you deal with is dense grid layouts since you don't know where things end up. It would be sad not to handle that. And I'm not sure how something like that would interact with spatial nav, if it even should or has to.

[stroobandt]

I have followed this issue trail all the way from the August 2017 issue #1748 "Please add "tab-index" to CSS specification"
We are now at the eve of 2020 and one can still not use something as useful as this:

input[readonly="readonly"] {tabindex: -1;}

From the above discussion, it is understood that a more comprehensive navigation solution is envisioned, which is fine. However, in the meantime, does one really has to go over one's HTML code and manually add tabindex="-1" like it is 1994?

For the desperate, here is how you can set tabindex dynamically using plain JavaScript.

[waterplea]

Why we cannot at least have focus follow order CSS rule for flexbox and grid? order accessibility drawback is extremely severe because of that. If you want an accessible page it's useless, just like tabIndex of any value, other than -1 and 0, because there is no way to isolate it in a particular section. When was the last time you saw any complex site with no independent parts, that just know about every focusable element to control tabIndex properly?

[jimmyfrasche]

@waterplea see #7387