A keyboard user needs a predictable order for entering, moving through, and leaving a chart

What it is

Keyboard users moving through a chart rely on a mental model of the traversal order: where they enter, which elements pass in what sequence, and where it ends. Visual users' scan order self-organizes from spatial layout (left to right, whole before detail), while keyboard traversal order is explicitly defined by the designer—when the defined order matches readers' spatial expectations, keyboard users can build a chart map equivalent to visual users'; when the order is random or counterintuitive, every move is a guess, and traversal degrades from navigation to trial-and-error.

Why it happens

A predictable order works by translating the visual layout's logical order into a linear sequence: time series traverse chronologically (early to late, matching how readers read the axis), category charts traverse in display or value order (matching the bars' arrangement), multi-series charts traverse series-first then points, following legend order. The operational test for "predictable": can a user who only hears the traversal order (not seeing the screen) predict what comes next? The classic failure of order-space conflict is charts whose DOM order differs from visual order (data alphabetical in code, sorted by value on screen)—screen-reader users hear one arrangement while visual users see another, and the two groups build entirely different structural impressions of the same chart. The order must also connect to entry/exit paths: Tab lands on the first element, Escape or continued Tab leaves—only with fixed, predictable entry and exit does the traversal order close into a coherent model.

Where it stops holding

Predictability couples with traversal granularity: fine-grained (per-point) traversal demands point-level order predictability (time series are naturally ordered—easy; scatter plots have no natural order and need an explicit definition like "by value"); coarse granularity (overall summary plus segments) lowers the order requirement at the cost of per-point access. The order is also constrained by interaction hierarchy—extending into the same group's level switching: the order holds within the "series level" and the "point level," with a fixed switch key between the two, before the model is complete. When the graphic changes dynamically (a filter changes the dataset), the order rule must reapply rather than preserving the old order—users remember the rule, not a specific element list.

Applying it

• Define default traversal orders per chart type: time series chronological ascending, category charts in on-screen order, multi-series charts in legend order.
• Keep DOM/accessibility-tree order consistent with visual order; when data sorting changes, update the traversal order in sync.
• Fix the entry (Tab lands on the first element) and exit (Escape or Tab out) positions, documenting them in the keyboard interaction contract.
• Verification: blindfold the screen and traverse a chart by keyboard alone, attempting to rebuild its structure mentally; failure to rebuild or frequent disorientation means the order is unpredictable.

Related

• Same group: U11.02.2 Traversal should support switching between series and data-point levels · U11.02.3 Announcements must include identifier, value, and unit · U11.02.4 Overall trends need a readable summary layer rather than point-by-point listening · U11.02.5 View changes caused by interaction must be announced
• Nearby: U11.01.3 Interactive charts must support keyboard traversal · U11.02.2 Traversal should support switching between series and data-point levels
• Search terms: focus order · traversal order · keyboard navigation