WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Keyboard focus order for re-ordered elements


From: Alastair Campbell
Date: Jun 16, 2017 2:54AM

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 [1] 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.



1] https://24ways.org/2016/css-writing-modes/