An animated chart that can't be paused or stepped forces every viewer to keep pace with its own clock

What it is

Animated charts (racing bar charts, scrolling timelines, auto-rotating dashboards) distribute their information over time: the frame at any instant shows only one state slice of the data. Control is the first principle of animation accessibility: auto-play must have an explicit pause control; once paused, frame (or state) stepping must let users examine every state at their own speed. Without control, an animated chart allocates information unfairly across reading speeds—users who cannot keep up are forced to give up.

Why it happens

The control mechanism addresses the conflict between individual reading speeds and the animation's fixed rate: the animation plays at the designer's chosen speed while each reader's cognitive processing rate (reading values, comparing, understanding) is an individual variable, and the two match only when a slower reader happens to keep up. Pause transfers rate control to the user; stepping discretizes "when to advance" into the user's explicit action—indispensable (not enhancement) for anyone taking notes, comparing two states, or using assistive technology. Keyboard reachability is how control is realized (extending into the same group's keyboard traversal): pause/play and stepping must be keyboard-triggerable (space to pause, arrows to step) with the controls present in the focus order. Auto-play itself has limits: purely decorative animation (loading indicators, ambient motion) may auto-play at low salience; information-bearing auto-play should not exceed one cycle by default, and looping requires a visible stop—infinitely looping information animation locks users into passive watching.

Where it stops holding

Pause and step granularity involves trade-offs: for continuous animation (a growing trend), "frame stepping" should be discretized into key states (one year per step, one phase per step) rather than literal render frames—the step unit is "one meaningful state," not "one frame." Control visibility is another boundary: a pause buried in a menu is too slow for a user who urgently needs to stop (early signs of vestibular discomfort); information-bearing auto-playing animations should place the pause control directly beside the animation. Touch environments need equivalent operations (tap to pause, swipe to step) defined alongside the keyboard contract.

Applying it

• Provide pause/play and step controls beside every auto-playing information animation, keyboard-reachable (space pauses, arrows step), with usage hints visible.
• Define the step unit as a meaningful state (year, phase); the pause position is the stepping start.
• Cap auto-play at one cycle; looping requires an explicit stop.
• Verification: using only the keyboard, complete "pause the animation and step to a given year to read its value"; failure means control is missing.

Related

• Same group: U11.03.2 States existing only during playback need static equivalents · U11.03.3 Rapid flashing and high-contrast motion can trigger discomfort or seizures · U11.03.4 Transition animations must respect the system's reduced-motion preference · U11.03.5 Too-short animation duration leaves intermediate states unreadable
• Nearby: U11.01.3 Interactive charts must support keyboard traversal · U11.03.2 States existing only during playback need static equivalents
• Search terms: animation control · pause button · frame stepping