What determines focus order on a screen, and why is a focus order that contradicts the visual layout a defect?
answer
- Ask what the platform actually traverses
- The picture is painted after the structure
- Visual reordering leaves the traversal sequence untouched
- Two Level A criteria name this failure
basics
~20 sFocus order follows the order controls appear in a screen's underlying structure, not where they are painted. When the two disagree, keyboard users jump unpredictably, and WCAG treats that as a Focus Order failure, not a cosmetic flaw.
solid answer
~50 sFocus moves in the order the platform builds the screen: the focusable controls are visited in the sequence they occur in the underlying structure a UI framework hands to the platform, and only an explicit override changes that. Layout can reorder what you *see* -- a column moved beside another, a summary pulled above its inputs -- without touching that sequence, so the two drift apart. A keyboard user then tabs from the top of the screen to something at the bottom and back up, with no way to predict the next stop and no way to know when they have covered everything. WCAG names it: **2.4.3 Focus Order (Level A)** requires focus to arrive in an order that preserves meaning and operability, and **1.3.2 Meaningful Sequence (Level A)** covers the same divergence for reading sequence. It is a failure at the lowest level, not a nuisance.
code
pseudocode · 9 linesstructure (what focus traverses) layout (what the eye sees)
1 service selector [ cost summary ] <- painted first
2 address field [ service selector ]
3 date field [ address field ]
4 confirm control [ date field ]
5 cost summary: change item [ confirm control ]
6 cost summary: remove item
keyboard reaches the summary LAST; the eye reads it FIRSTgo deeper
Be ready to say that focus order comes from the screen's underlying structure rather than from where things are painted, and that a keyboard user has no way to preview where focus will land next.
Explain how a layout change reorders what is seen without touching the traversal sequence, and why matching the structure to the intended reading sequence is the maintainable fix rather than forcing positions.
Show how you catch this on real screens: traverse forward and backward with no pointer, compare against the intended reading sequence, and treat a mismatch as a Level A conformance failure that blocks a release rather than a backlog item.
Own the systemic angle. A component set that lets teams reorder visually without owning traversal order will keep producing this defect, so the answer is an authoring rule plus a gate, not a per-screen bug hunt.
## Two orders, one screen **Focus** is the single point on a screen that receives keyboard input; **focus order** is the sequence in which a keyboard user reaches the operable controls moving forward, and the reverse of it moving back. It is not a property of the picture the user sees. Every platform builds a screen from an underlying structure -- a tree of nodes a UI framework hands to the platform -- and focus order is a traversal of that tree, visiting the nodes the platform treats as focusable in the order they occur. **Layout is a separate stage.** A modern layout system is free to place a node anywhere: reverse a row, reflow a stack into columns, pull a summary above the inputs that produce it. None of that rewrites the structure. So a screen carries at least three orderings of the same content, and they agree only until somebody reorders something visually. | Ordering | What produces it | Who experiences it | | --- | --- | --- | | Focus order | traversal of the focusable nodes in the structure | keyboard, switch and voice users | | Reading order | traversal of the content nodes in the structure | anyone consuming the screen non-visually | | Visual order | layout and painting | sighted pointer users | The defect is rarely "the focus order is wrong" in isolation. The defect is that **two orderings a user reasonably assumes are the same have silently diverged.** ## Why divergence is a defect and not a nuisance A pointer user chooses where to go: they see the whole screen and aim. A keyboard user has **no preview**: they learn where focus is only after it arrives, one stop at a time, and build their map of the screen by walking it. When the walk contradicts the picture: - They cannot predict the next stop, so every press is a small gamble. - They lose the grouping that adjacency conveys -- a field, its hint and its error stop being neighbours, so the hint arrives attached to the wrong thing. - They cannot tell whether they have reached everything, because "keep going until it repeats" is their only completeness check. - Focus can land somewhere invisible -- a stop layout pushed off-screen or behind another panel -- and they are now typing into something they cannot see. WCAG names this failure twice, and both times at the lowest conformance level. **2.4.3 Focus Order (Level A)** requires that focusable components receive focus in an order that preserves meaning and operability. **1.3.2 Meaningful Sequence (Level A)** requires that a correct reading sequence can be programmatically determined wherever sequence affects meaning. Level A is the floor rather than the aspiration: a conformance claim at any level fails while a Level A criterion fails. ## Forcing the order is the wrong repair The tempting fix is to override the sequence -- number the controls in the order you want them visited. It works on the day it is written and rots afterwards, for reasons that are identical on every platform: 1. An explicit override is **screen-wide, not local**. Once one control declares a position, it competes with every other focusable thing on the screen, including whatever a supplier component brings with it. 2. Every control added later has to be threaded into the same numbering, by someone who first has to discover the numbering exists. 3. Two components that each force their own order cannot be composed. (On the web this override is spelled `tabindex` with a positive value; native toolkits expose an equivalent ordering property, and the failure mode is the same in both.) The durable fix runs the other way: **make the underlying structure match the order the content should be consumed in, and let layout do the visual arrangement.** If the summary belongs first in the reading sequence, put it first in the structure and paint it wherever the design wants it. ## Finding it Put the pointer away. Traverse the screen forward, writing down the sequence, then traverse it backward and check the reverse walk mirrors the forward one. Three things to watch for: - **A jump** -- focus leaves a group of related controls and comes back to it later. - **A disappearance** -- focus is somewhere, but nothing on the screen says where. - **An asymmetry** -- the backward walk is not the forward walk reversed, which usually means something is moving focus programmatically. A worked case. A council waste-collection service redesigns its bulky-item booking screen so a running cost summary is painted at the top, above the address and date inputs it summarises. The summary was appended to the structure last, because it depends on those inputs. Of the 27 focusable stops on that screen, its two controls -- "change item" and "remove item" -- sit at stops 26 and 27. A pointer user sees them first; a keyboard user reaches them after everything else, having already committed to the values they were meant to review. Nothing is mislabelled and nothing is unreachable, and the screen still fails at Level A. Dynamic content deserves the same care. When expanding a section reveals new controls, they belong **immediately after the control that revealed them**, so the walk still matches what just appeared; on collapsing, focus belongs back on that same control.
- Why not simply force each control's position in the focus order to match the layout?An explicit override is screen-wide, not local: once one control declares a position it competes with every other focusable thing on the screen, including anything a supplier component brings with it. Every control added later has to be threaded into the same numbering by someone who first has to discover it exists, and two components that each force an order cannot be composed. Reorder the underlying structure instead, and let layout arrange the picture.
- A section expands and reveals three new controls. Where do they belong in the focus order?Immediately after the control that revealed them, so the walk still matches what just appeared. If they land at the end of the screen instead, the user has to traverse everything else to reach content they explicitly asked for. On collapsing, focus belongs back on the control that was used to expand it, rather than being dropped somewhere the user cannot see.
- What does traversing a screen backward tell you that traversing it forward does not?Whether anything is moving focus programmatically. The backward walk should be the exact mirror of the forward one; when it is not, something is intercepting traversal -- a validation handler, a scroll-into-view, or a component restoring its own last position. Backward traversal also catches stops that exist in only one direction, which forward-only testing never reveals.
Focus order is the running order of a concert; visual layout is the seating plan of the venue. Rearranging the seats changes nothing about which band plays next.
saying these in an interview costs you the question
- Says focus order is whatever the visual layout looks like
- Treats a jumping focus order as a minor polish item
- Reaches for forced order numbers as the first fix
- Assumes only users who cannot see are affected
- Claims focus order only matters on data-entry screens