F16: Scrolling Content Without Pause Control

"A page has a scrolling news ticker without a mechanism to pause it. Some users are unable to read the scrolling content."

That sentence — direct from W3C's official failure document F16 (opens in new window) — is deceptively simple. One scrolling element. No pause button. Real people locked out of real content. The failure is technically trivial to describe and surprisingly common to encounter.

F16 documents a specific violation of WCAG 2.2 Success Criterion 2.2.2: Pause, Stop, Hide (opens in new window). The rule: if content moves, blinks, scrolls, or auto-updates for more than five seconds — and that movement isn't essential to the activity — users must have a way to pause it, stop it, or hide it. No mechanism means a failure. Full stop.

The Failure Pattern

The canonical example from the W3C document is a scrolling news ticker. Here's what that typically looks like in code:

<!-- FAILURE: Scrolling marquee with no pause control -->
<marquee behavior="scroll" direction="left" scrollamount="3">
  Breaking: City council votes on new transit plan | Markets up 1.2% | Weather: Rain expected Thursday
</marquee>

The <marquee> element is the obvious offender — deprecated, but still encountered in legacy codebases. CSS animations create the same problem:

/* FAILURE: CSS ticker with no user control */
keyframes ticker {
  0   { transform: translateX(100); }
  100 { transform: translateX(-100); }
}
.news-ticker {
  animation: ticker  linear infinite;
}

Neither implementation gives the user any agency. The content moves. Users cannot stop it. Under SC 2.2.2 (opens in new window), this is a failure regardless of how the animation is technically implemented — the criterion applies to all technologies that support visual movement or scrolling.

Why This Matters for Real People

The W3C document names two groups specifically: users with low vision and users with cognitive disabilities. The impact on each is distinct.

For users with low vision, scrolling content creates a moving target. Screen magnification means a user may only see a portion of the viewport at any time. When text scrolls past at a fixed rate, the user cannot slow it down, cannot reposition, cannot catch what they missed. The content is technically present and technically visible — and practically inaccessible.

For users with cognitive disabilities, particularly those affecting reading speed, attention, or processing — ADHD, traumatic brain injury, dyslexia — scrolling text imposes an external pace on a process that requires internal pacing. Reading isn't passive reception. It requires time to decode, process, and retain. A ticker that moves at the designer's preferred speed may be completely unreadable for someone who needs twice as long.

There's a third group worth naming: users who experience vestibular disorders or motion sensitivity. Scrolling content can trigger genuine physical discomfort — nausea, dizziness, disorientation. While WCAG 2.3.3 (Animation from Interactions) addresses some of this territory, F16 captures the baseline failure: movement that cannot be stopped is movement that cannot be accommodated.

The broader pattern here raises a question worth sitting with. Scrolling tickers exist because someone decided they looked dynamic, conveyed activity, or packed more content into limited screen space. Those are design preferences. The users who cannot read the content aren't a niche edge case — they represent a significant portion of any real audience. What does it mean for a design decision to optimize for the appearance of information delivery while actually blocking information access for a meaningful segment of users?

The Fix

The corrected pattern requires a user-controlled mechanism. The simplest implementation pairs the animation with a pause/play toggle:

<!-- FIX: Scrolling ticker with pause control -->
<div class="ticker-wrapper">
  <button id="ticker-toggle" aria-pressed="false" aria-label="Pause news ticker">
    Pause
  </button>
  <div class="ticker" id="news-ticker" aria-live="off">
    <span>Breaking: City council votes on new transit plan</span>
    <span>Markets up 1.2%</span>
    <span>Weather: Rain expected Thursday</span>
  </div>
</div>

// Toggle animation state
const btn = document.getElementById('ticker-toggle');
const ticker = document.getElementById('news-ticker');
btn.addEventListener('click', () => {
  const isPaused = ticker.style.animationPlayState === 'paused';
  ticker.style.animationPlayState = isPaused  'running' : 'paused';
  btn.setAttribute('aria-pressed', !isPaused);
  btn.textContent = isPaused  'Pause' : 'Resume';
  btn.setAttribute('aria-label', isPaused  'Pause news ticker' : 'Resume news ticker');
});

A few things to note about this implementation. The aria-pressed attribute communicates toggle state to screen reader users. The aria-live="off" on the ticker itself prevents screen readers from announcing every content change as the ticker scrolls — that would be its own usability problem. And the button label updates to reflect current state, not the action that was just taken.

For teams considering whether to keep the ticker at all: static content with periodic refresh, or a collapsed expandable section, often serves users better than any scrolling implementation. The pause mechanism satisfies WCAG. Removing the animation removes the problem.

Applying This in Practice

Automated testing tools catch some instances of F16 — particularly <marquee> elements, which are flagged reliably. CSS-based animations are harder. Tools like axe-core can flag animation and transition properties, but determining whether a pause mechanism exists requires human judgment. Our research on testing methodology confirms this pattern: automated tools catch the obvious structural failures while missing contextual implementation gaps.

For code review, the practical checklist is short:

• Flag any CSS animation or transition on content elements — ask whether a pause control exists
• Search for <marquee> in templates — deprecate and replace
• Check JavaScript-driven content rotation (carousels, auto-advancing slides) — SC 2.2.2 applies there too
• Test the pause control with a keyboard — if it requires a mouse, it's not accessible

Design review should catch this earlier. Any component spec that includes scrolling, rotating, or auto-updating content should require a pause control as part of the design, not as an accessibility retrofit.

One implementation detail that teams often miss: the pause mechanism must be reachable before the moving content in the DOM order. If a keyboard user has to tab past the scrolling ticker to reach the pause button, they've already been exposed to the barrier.

CORS Perspective

From a strategic alignment lens, F16 is a useful case study in how design intent and access outcomes diverge. Scrolling tickers signal activity and freshness — values that leadership often associates with engagement. The business case for the pause control isn't complicated: the same content, readable by more people, with a single button added. The risk calculus is straightforward too, since SC 2.2.2 is a Level A requirement — the baseline tier — meaning its absence represents a fundamental compliance gap, not a refinement. Organizations that have worked through multi-standard compliance frameworks will recognize that Level A failures carry disproportionate legal and reputational exposure relative to their technical cost to fix. A pause button is rarely a budget conversation. It's a prioritization one.