Discussion:
FlexBox keyboard disconnect - new property proposal
(too old to reply)
Léonie Watson
2016-06-17 09:53:35 UTC
Permalink
Raw Message
Hello CSS,

Had an impromptu chat with Simon Pieters and Greg Whitworth about the
FlexBox keyboard disconect [1]. It resulted in an idea for a new CSS
property...

At the moment the problem is that FlexBox can create a disconnect between
the DOM order and visual order. This affects sighted keyboard users - or at
least exacerbates the disconnect that has existed since CSS layouts were
first a thing.

There is a workaround in Firefox, whereby the keyboard order matches the
visual flex order, instead of the DOM order. On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?

It seems like it would be good to have a property to enable developers to
choose whether the keyboard order matched the DOM order or the flex order.
Off the top of my head, something like:

tab-order: dom;

or:

tab-order: flex;
From the work Mozilla has already done, and this briefest of conversations
with Greg and Simon, it seems there is energy from the browser vendors to
find a solution to this problem. Hoping this idea kicks off further
discussion...

Léonie.
[1] http://tink.uk/flexbox-the-keyboard-navigation-disconnect/
--
@LeonieWatson tink.uk Carpe diem
Henrik Andersson
2016-06-17 11:30:44 UTC
Permalink
Raw Message
Post by Léonie Watson
Hello CSS,
Had an impromptu chat with Simon Pieters and Greg Whitworth about the
FlexBox keyboard disconect [1]. It resulted in an idea for a new CSS
property...
At the moment the problem is that FlexBox can create a disconnect between
the DOM order and visual order. This affects sighted keyboard users - or at
least exacerbates the disconnect that has existed since CSS layouts were
first a thing.
There is a workaround in Firefox, whereby the keyboard order matches the
visual flex order, instead of the DOM order. On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?
It seems like it would be good to have a property to enable developers to
choose whether the keyboard order matched the DOM order or the flex order.
tab-order: dom;
tab-order: flex;
From the work Mozilla has already done, and this briefest of conversations
with Greg and Simon, it seems there is energy from the browser vendors to
find a solution to this problem. Hoping this idea kicks off further
discussion...
Léonie.
[1] http://tink.uk/flexbox-the-keyboard-navigation-disconnect/
Nice idea in theory, but you seem to be focusing too much on flex being
the only tab ordering affecting layout module. I'd try to avoid layout
module specific keywords here.
Léonie Watson
2016-06-17 12:11:23 UTC
Permalink
Raw Message
Sent: 17 June 2016 13:31
Nice idea in theory, but you seem to be focusing too much on flex being
the
only tab ordering affecting layout module. I'd try to avoid layout module
specific keywords here.
Thanks for the feedback Henrik. Can you suggest some less specific language
to help guide this idea in the right direction?

Léonie.
Brian Kardell
2016-06-17 14:52:09 UTC
Permalink
Raw Message
On Fri, Jun 17, 2016 at 5:53 AM, Léonie Watson <***@tink.uk> wrote:

[snip]
Post by Léonie Watson
On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?
Can you provide an example where the keyboard disconnect is actually
useful? I'm not saying such a case doesn't exist, simply that it is
non-obvious and if that is a use-case it would be helpful to have an
example documented.
Post by Léonie Watson
Léonie.
[1] http://tink.uk/flexbox-the-keyboard-navigation-disconnect/
--
@LeonieWatson tink.uk Carpe diem
--
Brian Kardell :: @briankardell
Tab Atkins Jr.
2016-06-17 21:06:33 UTC
Permalink
Raw Message
Post by Léonie Watson
On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?
Can you provide an example where the keyboard disconnect is actually useful?
I'm not saying such a case doesn't exist, simply that it is non-obvious and
if that is a use-case it would be helpful to have an example documented.
Long-standing accessibility advice is to put your "main content" first
in the DOM and things like sidebars and advertising later, using CSS
to arrange them as desired. This is the origin of the "holy grail
layout" (float-based) and similar CSS hackery - Flexbox handles these
cases much easier (example in
<https://drafts.csswg.org/css-flexbox/#order-accessibility>). Or
check out the Grid example
<https://drafts.csswg.org/css-grid/#source-independence> - the
portrait and landscape layouts are slightly different in visual order,
but each layout makes a lot of sense individually.

As Henrik said (and fantasai and I and others have repeatedly said in
the past), this has nothing to do with flexbox itself - CSS offers a
wealth of ways to lay out a page such that the visual and DOM orders
don't match. And there's more than just tab order that are affected
by the mismatch - for example, selecting text across element
boundaries gets frankly *silly* when you move elements around in
interesting ways, where highlighting from one point to another can end
up highlighting completely unexpected parts of the page.

So there are some complicated intersections of issues. Tab order is
relatively simple conceptually - one can imagine a simple switch (in
CSS or elsewhere) that resets the way tab-ordering is figured within
the subtree to match the (writing-mode determined?) visual order.
There's more detail to be worked out there, but it's not too hard to
imagine.

Selection is a much thornier issue, because (a) I think you might
*always* want visual selection? Can't think of when you'd *want* DOM
selection, and (b) you actually have to change the relevant API, to
return a multi-range object.

Anyway, I'm supportive of an effort to help things here, but we'll
need implementor interest in changing their tab-order implementation
to be significantly more complex.

~TJ
Florian Rivoal
2016-06-18 15:01:20 UTC
Permalink
Raw Message
Post by Tab Atkins Jr.
Post by Léonie Watson
On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?
Can you provide an example where the keyboard disconnect is actually useful?
I'm not saying such a case doesn't exist, simply that it is non-obvious and
if that is a use-case it would be helpful to have an example documented.
Long-standing accessibility advice is to put your "main content" first
in the DOM and things like sidebars and advertising later, using CSS
to arrange them as desired. This is the origin of the "holy grail
layout" (float-based) and similar CSS hackery - Flexbox handles these
cases much easier (example in
<https://drafts.csswg.org/css-flexbox/#order-accessibility>). Or
check out the Grid example
<https://drafts.csswg.org/css-grid/#source-independence> - the
portrait and landscape layouts are slightly different in visual order,
but each layout makes a lot of sense individually.
As Henrik said (and fantasai and I and others have repeatedly said in
the past), this has nothing to do with flexbox itself - CSS offers a
wealth of ways to lay out a page such that the visual and DOM orders
don't match.
I would also add that not only can the visual order and the DOM order
get out of sync, since the visual rendering is a 2D thing rather than
a linear one, There isn't necessarily an order. Some 2D documents are
still essentially linear (e.g. top menu, then content, then footer),
but many are not (e.g. same thing with side bars, or anything a tad
complex).

- Florian
Amelia Bellamy-Royds
2016-06-19 08:56:41 UTC
Permalink
Raw Message
Florian's point about there not necessarily being one clear "visual order"
is something I've noted as well. For flex-box containers there is a clear
order, but for grid, floats, and absolute positioning it gets more complex.

Maybe there needs to be 2 different "visual" keywords: column-first versus
row-first

i.e., for column-first you would work your way down the "start" (i.e., left
for LTR text) edge of the page, including all boxes that touch that edge.
Then you would find the boxes with the next-smallest left offset, and go
through them top to bottom, and so on.

For row-first, you would do the reverse, sorting boxes first by their top
offset, then by their left/right offset.

Another complication is how to handle nesting. Do you group the sorting of
boxes by stacking context, or by containment block? This is a property
you'd often want to control sibling elements in a small region of the page
(e.g., children of a flexbox container), but you may want the freedom to
re-order elements who are nephews or cousins in the DOM tree.

And for Brian: a few more examples of cases where a "keyboard disconnect"
is useful:

- Your navigation list includes a "HOME" link represented by company
logo but also text links to various pages. On wide screens, you want the
HOME logo to be large in the middle of the header and the other links
pushed to either side. On smaller screens, you want it all in a single
column, with the logo at the top. For non-visual users, you don't want to
re-order the items in the navigation list based on screen size, because
that would be unnecessary confusion. Even for sighted users, the visual
prominence of the large center logo means it is naturally first, even if
not first left-to-right.

- You're presenting a Top 3 list of some sort using the Olympic medal
podium as a visual representation. Left-to-right, the order is 2-1-3, but
of course you want the entries to be still read out / tabbed through in
1-2-3 order. Again, some sort of visual prominence or cross-axis alignment
would be used to make the middle entry more prominent and obviously first
to visual users.


The issue of 2D keyboard navigation is something we've discussed often in
the SVG Accessibility Task Force. One thing that would be helpful is for
user agents to offer alternative ways for keyboard users to move around the
page, other than tab order. Specifically, if you could press a modifier
key and then use arrows to jump from one region to another based on actual
layout. That's probably a separate and additional feature to what is
proposed here, but I wanted to mention it.

~Amelia
Post by Florian Rivoal
I would also add that not only can the visual order and the DOM order
get out of sync, since the visual rendering is a 2D thing rather than
a linear one, There isn't necessarily an order. Some 2D documents are
still essentially linear (e.g. top menu, then content, then footer),
but many are not (e.g. same thing with side bars, or anything a tad
complex).
Florian Rivoal
2016-06-23 05:29:34 UTC
Permalink
Raw Message
Maybe there needs to be 2 different "visual" keywords: column-first versus row-first
[...]
Another complication is how to handle nesting.
I think as soon as you try to do visual 2D navigation rather than logical order navigation, there's a whole host of complications. Nesting, grid layouts, complex layouts that not only aren't linear but don't even fit in rows and columns, implied hierarchy via size or color or contrast, overlapping elements and transparency, animated things that move around or disappear...

Heuristics to get this right are hard and will fail occasionally, and that's why we have https://drafts.csswg.org/css-ui/#keyboard
The issue of 2D keyboard navigation is something we've discussed often in the SVG Accessibility Task Force. One thing that would be helpful is for user agents to offer alternative ways for keyboard users to move around the page, other than tab order. Specifically, if you could press a modifier key and then use arrows to jump from one region to another based on actual layout. That's probably a separate and additional feature to what is proposed here, but I wanted to mention it.
Right. I think that's what it boils down to: either you want a linear logical order with a meaningful next and previous, and it is DOM based, or you want full spatial navigation with up/down/left/right, and it is layout based.

Both are useful, both should be possible to use in the same browsing context, but they are different, and trying to address layout-based concerns in the logical order sounds like an intractable problem to me.

If anyone want to try spatial navigation out and haven't yet, I've blogged about how it works in a few browsers: http://florian.rivoal.net/blog/2015/04/controlling-spatial-navigation/

- Florian

Greg Whitworth
2016-06-20 20:39:04 UTC
Permalink
Raw Message
As Henrik said (and fantasai and I and others have repeatedly said in the past), this has nothing to do with flexbox itself -
CSS offers a wealth of ways to lay out a page such that the visual and DOM orders don't match.
<snip>
Anyway, I'm supportive of an effort to help things here, but we'll need
implementor interest in changing their tab-order implementation to be
significantly more complex.
~TJ
+Alan/Rossen for visibility

A little clarification,

This is similar to what Simon and I stated in this brief discussion, that this is not flex specific, so we shouldn't focus purely on the layout mode for the underlying issue. Additionally, we stated that we need to have the full CSSWG present for the discussion as the property suggestion was merely one potential way to solve the problem and would require feedback from
Loading...