A tooltip that only appears on hover locks out anyone who can't or won't use a mouse

What it is

Users with motor impairments, screen-reader users, and the many ordinary users who prefer keyboard operation cannot—or cannot conveniently—hover a mouse precisely over chart data points. If an interactive chart's tooltips, click-to-drill, and zoom/pan work only by mouse, those functions simply do not exist for keyboard users. Keyboard traversal means every interactive function is reachable and operable via the keyboard (Tab, arrow keys, Enter), with the current focus clearly indicated both visually and non-visually.

Why it happens

Keyboard access works by bringing chart elements into the focus order and giving them semantics: SVG- or DOM-based chart elements can receive focus (tabindex), respond to keyboard events, and expose roles and states through the accessibility tree (ARIA). The central design difficulty is focus granularity—placing every data point in the Tab order means hundreds of Tabs to escape the chart; the sound solution is layered traversal: the chart as a whole is one tab stop (a single Tab enters it), arrow keys move between data points inside it (arrow navigation does not consume the Tab order), Enter activates selection or drill-down, and Escape returns to the whole-chart focus. Focus indication is the parallel requirement: the visible focus ring must not be removed for aesthetics (low-vision users rely on it for location), while screen-reader users rely on semantic announcement of focus ("current point: March, sales 420K"). Interactive charts also have a discoverability problem: mouse-only affordances (hover) are undiscoverable to keyboard users, requiring explicit keyboard hints ("use arrow keys to browse data points") or binding hover content to focus events as well.

Where it stops holding

Full keyboard support carries real engineering cost: canvas-rendered charts (the mainstream choice for high-performance scenes) have no native DOM elements, requiring a manually maintained virtual focus layer (a transparent focus proxy overlaying the canvas)—the technical root of many chart libraries' accessibility gaps. Traversal design must also balance typical and keyboard-first users: making every data point traversable is necessary for motor-impaired users yet lengthens the Tab order, so the page level needs skip mechanisms (skip links). Touch users form a third input channel: hover does not exist on touch, so touch targets need minimum sizes (44px class) and alternative interactions (tap to show the tooltip). Compatibility across the three input modalities defines the full boundary of interactive-chart accessibility.

Applying it

• Make the chart container focusable (tabindex=0); inside, arrow keys traverse points, Enter activates, Escape exits—establish one consistent keyboard contract and document it in help.
• Keep the default focus ring or an equivalent high-contrast indicator; sync screen-reader announcements (aria-live) as focus moves.
• Bind hover-tooltip content to keyboard focus events so keyboard users read exactly what mouse users read.
• Verification: unplug the mouse and complete the task "browse all data points and view one point's details" using only the keyboard; failure means keyboard traversal falls short.

Related

• Same group: U11.01.1 Graphics need a text summary as equivalent content · U11.01.2 The data table is the most reliable alternative form
• Nearby: U7.08.5 Drillable elements need a clickable visual cue · U11.01.2 The data table is the most reliable alternative form
• Search terms: keyboard accessibility · focus management · ARIA