W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2018

[csswg-drafts] Reordered sequential navigation (#3369)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Mon, 03 Dec 2018 07:42:04 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-386694319-1543822913-sysbot+gh@w3.org>
frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== Reordered sequential navigation ==

Migrated from https://github.com/WICG/spatial-navigation/issues/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](https://github.com/WICG/spatial-navigation/wiki/Use-cases-for-reordering-sequential-navigation). 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](https://github.com/WICG/spatial-navigation/wiki/Historical-discussions-of-reordering-sequential-navigation) 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3369 using your GitHub account
Received on Monday, 3 December 2018 07:42:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:40 UTC