Pause, Stop, Hide Controls for Auto-Updating Data

Live dashboards, log viewers, tickers and auto-refreshing tables update by themselves. SC 2.2.2 requires that users can pause, stop or hide auto-updating information that starts automatically and is presented alongside other content, unless the updates are essential. In practice, a pause control makes data UIs usable for screen reader users reading a changing table, for people with attention difficulties and for anyone who needs to compare values without them changing.

This guide belongs to real-time data stream announcements.

Spec reference

SC 2.2.2 Pause, Stop, Hide (A) — for moving, blinking or scrolling content lasting more than 5 seconds, and for auto-updating information, a mechanism to pause, stop or hide it (or control update frequency for auto-updating content).
SC 2.2.1 Timing Adjustable (A) — related, for time limits.
SC 4.1.2 (A) — pause control exposes its state.
prefers-reduced-motion — reduce non-essential motion by default.

Pause freezes the view, not the data.

When to use — and when not to

Add pause controls to any content that updates automatically while users might be reading or interacting with it: dashboards, feeds, live tables, logs, tickers, carousels of metrics.

Updates that are essential to the activity (a live auction where stale prices would mislead) may be exempt, but even then, offer a way to slow or hide motion. The misapplication: a pause button that stops the animation but keeps replacing the table data underneath, so screen reader users still read shifting values.

Annotated code example

<div class="live-toolbar">
  <button type="button" id="pause" aria-pressed="false" aria-describedby="live-state">Pause updates</button>
  <span id="live-state">Live · updated 10:42:05</span>
</div>
<table id="orders">…</table>
<div role="status" class="sr-only" id="live-status"></div>

let paused = loadPref('paused') ?? false, queued = [];
feed.on('change', c => paused ? queued.push(c) : apply(c));
pauseBtn.onclick = () => {
  paused = !paused; savePref('paused', paused);
  pauseBtn.setAttribute('aria-pressed', String(paused));
  pauseBtn.textContent = paused ? 'Resume updates' : 'Pause updates';
  if (paused) { state.textContent = `Paused at ${now()}`; }
  else {
    const s = summarise(queued); queued.forEach(apply); queued = [];
    state.textContent = `Live · updated ${now()}`;
    status.textContent = `Resumed. ${s.changed} rows changed, ${s.added} new.`;
  }
};

Keyboard & AT behaviour

Action	Announcement
Activate Pause updates	“Pause updates, toggle button, pressed”
While paused	State text “Paused at 10:42:05” via description
Activate Resume updates	“Resumed. 14 rows changed, 3 new.”
Reduced motion on	Motion stopped by default; data still updates unless paused
Reload page	Paused state restored

Every type needs at least one control.

Step-by-step implementation

Inventory auto-updating regions. Anything that refreshes on a timer or a push feed.
Place controls early. Put the pause control before the content in reading order, so users reach it before the changing content.
Freeze for real. Stop applying updates to the displayed data; queue them.
Show state. “Paused at…” or “Live · updated…” text near the control.
Resume with a summary. Apply queued changes and announce a short summary.

Integration context

Hidden-tab pausing is covered in pausing live regions when the tab is hidden, throttling in throttling high-frequency aria-live updates, and logs in accessible live log viewers. Tickers are in ticker and price feed announcements, and dashboard refreshes in announcing dashboard refreshes.

Gotchas

Pause on focus is not enough. Pausing when focus enters a table helps keyboard users but not screen reader users in browse mode; provide an explicit control.

Multiple regions. One global pause for the page is simpler than many per-widget controls; offer both if widgets differ.

Server polling. Pausing the display can keep polling; for cost reasons you may stop polling and refresh on resume.

Edge cases

Edits while paused. If users edit paused data, reconcile with queued changes on resume and flag conflicts.
Long pauses. After a long pause, a full reload may be simpler than applying thousands of queued changes.
Critical alerts while paused. Errors and critical alerts should still be announced; say so near the control.

Worked example

An operations dashboard refreshed its incident table every five seconds. Screen reader users reading a row often heard a different incident halfway through. The team added a “Pause updates” toggle before the table, froze the displayed data while paused, showed “Paused at” text, summarised changes on resume and kept critical alerts active. Users paused while investigating an incident and resumed when done.

Common mistakes

Pausing animation but not data.
Controls after the content.
No paused indicator.
Silent resume.

Testing checklist

Every auto-updating region can be paused, stopped or hidden.
Controls appear before the content.
Pausing freezes displayed data.
Paused state is visible and exposed.
Resume announces a summary.

With NVDA, start reading a live table and confirm values change under you (the problem). Activate Pause updates, read again and confirm values stay stable. Wait, then resume and listen for the summary. Reload and confirm the paused state persists. Turn on reduced motion and confirm moving elements stop by default. Repeat in VoiceOver.

Update frequency as an alternative

For some content, a frequency control is friendlier than pause: “Update every 5 seconds / 1 minute / manually”. SC 2.2.2 accepts letting users control update frequency for auto-updating information. Manual mode with a Refresh button and a “Last updated” time suits screen reader users who want stability most of the time. Offer it in addition to pause in dashboards where some users need near-real-time data and others do not.

Writing the resume summary

Keep the resume summary to one sentence with counts: rows changed, rows added, rows removed. If one change matters more than others — a status turning critical — name it: “Resumed. 14 rows changed; incident 4821 is now critical.” Do not list every change; offer a “Show changes since pause” view that highlights changed rows with a text marker so users can review them at their own pace. Clear the markers on the next pause or after the user has visited them.

Key points

Put the pause control before the live content.
Pausing freezes the displayed data, not just the animation.
Show “Paused at” state and summarise changes on resume.
Remember the choice, and keep critical alerts active.

Testing with real users

Ask screen reader users and people with attention difficulties to complete a reading task on live data — finding and comparing two rows — with and without the pause control. The difference in success is usually large, and it gives the clearest argument for keeping the control prominent.

Design system notes

Provide a live data controller with pause, frequency, queued updates and resume summaries, and a standard toolbar placement before live content.

FAQ

Is a pause control required for all live data?

For auto-updating information presented with other content, unless essential, yes.

Does reduced motion satisfy 2.2.2?

It helps, but users without that setting still need a control.

Where should the control go?

Before the content in reading order.

Should paused data still update in the background?

Queue changes; apply on resume.

Are critical alerts paused too?

No; keep them active and say so.

Is hiding acceptable instead of pausing?

For decorative or secondary content, yes.

Ticker and price feed announcements — tickers
Pausing live regions when the tab is hidden — background tabs
Accessible live log viewers — logs

← Back to Real-Time Data Stream Announcements