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