E-mail List Archives
Thread: Keyboard focus order for re-ordered elements
Number of posts in this thread: 6 (In chronological order)
I posted an article recently I'd like to get some criticism of before I
start filling bugs for browsers.
The basic premise is that new CSS layout methods (flexbox, grid) allow for
re-ordering of elements that affect the order in which they are displayed.
When that happens, the visual keyboard order is disrupted:
The can happen due to developers not considering this issue, but even when
you do consider it there are cases with no solution unless the browsers
follow the CSS order.
Before I open (or re-open) browser bugs, is there any harm you can see from
changing to the CSS order?
What's the opposing argument?
I got a couple of comments on the blog post about keyboard focus order ,
I'd like to see if people agree/disagree with some conclusions.
"would it be preferable to serve a different content order based on the
viewport width at load time?"
You could, but it's an extra thing to think about (that people won't). The
point of CSS grids (and flexbox) is to declaratively specify your layout,
Patrick H. Lauke said:
"there may well be situations where an author who knows what they're doing
is explicitly relying on logical order being different from visual order."
Can anyone think of an example that doesn't then hinder the visual focus
order already? This has been an issue before flexbox and grid, I'm just
anticipating that the use of those will make it more common.
"is it safe to assume authors will always get it wrong?"
Thinking about it, I would say yes.
Around half of the examples in Rachel Andrew's Grid by Example re-order the
source (compared to a row-by-row order):
That is not a criticism of the examples, that is what grid is supposed to
So authors will get it 'wrong' by design. Therefore we need the user-agents
to recover this situation.
As Patrick pointed out, it's the reading order for screenreaders as well,
so I assume it would mean re-ordering the DOM and/or Accessibility Tree to
match the flexbox-order and a row-by-row heuristic for grids.
just to clarify - maybe I misunderstand and it's just a terminology issue - you wrote:
> Around half of the examples in Rachel Andrew's Grid by Example re-order the
> source (compared to a row-by-row order):
> That is not a criticism of the examples, that is what grid is supposed to
What do you mean by "re-order the source"? The source code order remains the same, what is changed is the visual order when zooming in, like in this example:
So that is nothing new? If developers are at all aware of the importance of source code order and focus order, they will realise that changing the visual position of grid elements will lead to unexpected content AND focus order (e.g. jump down to a navigation that comes first in source code but is put at the bottom in a responsive view).
I am not sure what you are getting at - are you making the point that some of those grid designs (like others) would violate 1.3.2 and 2.4.3 and should be avoided (or the behavour should repaired by some means (changing source code order, sniffing techniques, or even via currently badly supported things like aria-flowto)?
If what your were getting at is finding a way that the user agent will construct a new actual DOM content order in response to viewport width changes (i.e. do what authors would have to do via scripting), I find it difficult to imagine a clearcut logic for that that will not possibly upset all sorts of things done by the author.
> > Around half of the examples in Rachel Andrew's Grid by Example re-order
> > source (compared to a row-by-row order):
> > https://gridbyexample.com/examples/
> What do you mean by "re-order the source"?
Sorry, bad phrasing, the source does stay the same.
I meant that they re-order the layout visually, either by default in the
layout shown, or when re-sized.
My point is that (especially in responsive designs) we are in a no-win
It is impossible to create a usable layout that maintains the source code
It isn't that bad for screenreader users, you probably don't realise,
unless you also look at the screen to the extent you can.
However, it's a much bigger issue for switch and other keyboard-style users
who effectively tab through the page. Adrian Roselli did a little example
When I read Richard Schwerdtfeger's comments I thought he was right, but
we'd be able to provide guidance:
Now I think that it is impossible to do a good job on websites without a
change in user-agents.
So that is nothing new? If developers are at all aware of the importance of
> source code order and focus order, they will realise that changing the
> visual position of grid elements will lead to unexpected content AND focus
> order (e.g. jump down
to a navigation that comes first in source code but is put at the bottom in
> a responsive view).
The difference now is the flexbox and grids make that trivially easy, most
aren't aware of that importance, and even for those that are you are stuck
between good usability and accessibility, and accessibility will loose.
I am not sure what you are getting at - are you making the point that some
> of those grid designs (like others) would violate 1.3.2 and 2.4.3 and
> should be avoided (or the behavour should repaired by some means (changing
> source code order, sniffing techniques, or even via currently badly
> supported things like aria-flowto)?
With flexbox it is a linear, 1 dimensional mechanism so the solution is
easy: use the behaviour firefox used to have, and re-order the
accessibility tree to the flexbox ordering (I think that is what it did).
For grids it is harder, I am saying we need browsers to use a heuristic
(like Opera used to have) that uses a row-by-row column-by-column order.
Now would be the time to do it, before people invest in hacks to try and
get around these issues.
A little word of thanks to Jennifer Sutton for pointing me to other
people's article on this topic.
I've updated my article to quote the Filament group's article here:
Specifically the breadth of the problem:
> the majority of layouts we see on the web do not strictly follow HTML
source order, and for good reason: across viewport sizes, the usability of
a design can be dramatically improved by shifting the visual hierarchy,
scale, and order of the elements in a page. Indeed, the great promise of
CSS was to free us from the constraints of binding our HTML to any
particular visual presentation.
And the lack of reasonable solution:
> Given the choices of A) dynamically adapting our HTML source order for
every breakpoint, B) sending different HTML sources to each client, or C)
renumbering the tabindex attributes of all focusable elements to match
their rendered order, we emphatically choose option D) "Nope".
> For our client's particular tab order issues, we weren't able to do much
to improve the tab order in some of our layouts, but we did add some
navigational cues within the markup to help mitigate the problem.
I really think this can only be solved (properly) on the user-agent side.
The method for flexbox is straightforward (and already demonstrated by
The method for grids need not be horrendously complex, the algorithm at a
high level could be:
- Start at the top of the block flow direction (see  for the terms),
i.e. top down for western sites.
- When you encounter a grid, go along the 'inline direction', i.e. left to
right for western sites.
- When you run out of elements along the inline direction, continue down
the block direction until you hit the next element.
I.e. top-down, then left to right.