( Operable / WCAG 2.2.2 )
marquee element is used
What is this issue?
The page contains a <marquee> element, a non-standard HTML tag that automatically scrolls its text content horizontally or vertically for as long as it’s on the page, with no native pause, stop, or hide mechanism. <marquee> was removed from the HTML specification and is officially obsolete, but unlike <blink>, current browsers generally still implement its scrolling behavior, so pages using it still produce continuously moving text today.
None of marquee’s own attributes (scrollamount, scrolldelay, behavior, direction) provide any form of user control over the motion: they only adjust speed and direction, so there’s no attribute-level fix, only removal and replacement.
Why does this matter?
Text that scrolls continuously across the screen forces a reader’s eyes to track a moving target instead of reading at their own pace, which is disorienting for anyone with a vestibular condition, and simply exhausting to follow for anyone using screen magnification, where the moving text occupies a much larger share of the visible viewport than it does at normal zoom. A marquee that never stops gives the reader no natural pause point to catch up.
The effect compounds for slower readers generally: a scrolling ticker set at a pace comfortable for average reading speed is, by definition, too fast for anyone who reads more slowly, and there’s no way to slow it down, pause it to finish a sentence, or skip ahead; the content simply keeps moving regardless of whether anyone has actually finished reading it.
Who is affected?
- Cognitive disabilities: continuously moving text competes for attention and makes it difficult to focus on or process the scrolling content at a comfortable pace, with no way to pause and catch up.
- Low vision users: anyone using screen magnification sees a proportionally larger share of the moving text at once, making it harder to track visually as it scrolls past, and reading at a slower-than-average pace means the content is often gone before it’s been fully read.
What users experience
Priya has low vision and reads most pages at 250% browser zoom using her operating system’s built-in magnifier. On a company intranet homepage, a <marquee> scrolls upcoming holiday and policy announcements across a banner at the top. At her zoom level, only two or three words of the scrolling text are visible in the viewport at once, and by the time she’s read them, the next fragment has already replaced them; she never manages to read a complete announcement and eventually stops trying to read the banner at all.
How do I fix it?
Remove <marquee> entirely; there’s no accessible way to keep its automatic, uncontrollable scrolling, since none of its attributes add user control. This works because eliminating the element removes the underlying failure at the source rather than trying to patch behavior the tag was never built to support.
If scrolling or ticker-style content is genuinely needed (a news ticker, a rotating list of announcements), rebuild it as a CSS animation or JavaScript-driven carousel with a visible, keyboard-operable pause control, and consider whether a simpler static list with a “next” control might serve the same purpose without any automatic motion at all. Static content that a user can scan at their own pace is almost always a better experience than a controllable scrolling one, and it requires no pause logic to get right.
Code Examples
<marquee behavior="scroll" scrollamount="5">
Breaking news: sale ends today! Free shipping on orders over $50.
</marquee><!-- Method 1: static list (simplest, no motion to control) -->
<ul class="announcements">
<li>Breaking news: sale ends today!</li>
<li>Free shipping on orders over $50.</li>
</ul>
<!-- Method 2: CSS-animated ticker with a real pause control -->
<div class="ticker" aria-live="off">
<button type="button" aria-pressed="false" onclick="toggleTicker(this)">
Pause ticker
</button>
<p class="ticker-text">Breaking news: sale ends today!</p>
</div>Method 1 removes the motion problem by not scrolling at all: a static list a user can read at their own pace, which is the simplest fix whenever the content doesn’t genuinely need to move. Method 2 preserves a ticker-style visual pattern but adds the pause control WCAG 2.2.2 requires; toggleTicker would add or remove a CSS class that sets the animation to paused, giving the user real control over the motion.
Common Mistakes
Mistake: “Marquee is deprecated, so browsers probably don’t render it anymore anyway.” Unlike <blink>, most current browsers still implement marquee’s scrolling behavior despite its obsolete status; this is an active, visible failure on any page still using it, not dead markup a browser quietly ignores.
Mistake: “We can fix this by slowing down the scrollamount attribute.” Adjusting scroll speed changes how fast the text moves, not whether the user has any control over it: a slower marquee is still an uncontrollable one, and 2.2.2 requires a pause, stop, or hide mechanism, not merely a comfortable speed.
Mistake: “Replacing marquee with a CSS animation automatically fixes the accessibility problem.” A CSS @keyframes animation that scrolls text continuously with no pause control reproduces the identical failure in modern syntax; the WCAG requirement is about user control over motion, not about which technology produces the motion. The pause control is the actual fix, regardless of implementation.
How RedFlag Detects This
Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s marquee rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule checks for the presence of any <marquee> element in the DOM and flags it unconditionally, since the element provides no attribute-level way to add the required user control.
False negative: the check only looks for the literal <marquee> element; a CSS-animated ticker or carousel that reproduces the identical continuous, uncontrollable scrolling with no pause control is invisible to this check, since it uses no <marquee> markup at all. False positive: none typical, since the presence of the element is a straightforward, binary parse of markup already on the page. Manual step: check any CSS-animated or JavaScript-driven scrolling content on the page for a working pause, stop, or hide control, since the automated check only catches the specific deprecated element, not the broader class of uncontrolled motion.
Manual Testing
- Load the page in a browser and watch for at least ten seconds without interacting. Note any text that scrolls continuously across the screen.
- View the page source (or DevTools Elements panel) and search for
<marqueeto confirm whether the element is present. - If scrolling content is present (whether
<marquee>or a CSS/JS equivalent), confirm a visible, keyboard-operable pause, stop, or hide control exists nearby; if not, the check fails. - At 200% browser zoom, confirm how much of the scrolling text is visible in the viewport at once, and whether a slower reader would realistically be able to finish reading it before it scrolls away.
Related WCAG Success Criteria
2.2.2 Pause, Stop, Hide: For any moving, blinking, scrolling, or auto-updating content that starts automatically and lasts more than five seconds, the user must be able to pause, stop, or hide it, unless the movement is essential. Continuously scrolling marquee content with no such control is a direct failure of this requirement.
Related Issues
Page contains a blinking or scrolling element is the flickering sibling of this same failure: different motion (blink versus scroll), identical 2.2.2 criterion and identical fix principle: remove the uncontrollable motion or add a real pause control.
Page has no way to bypass repeated content, Page has no descriptive title, Heading is empty or contains only whitespace, Focus order does not match the visual or DOM order, and Element is skipped in the keyboard focus order are other structural, legacy-markup-era failures that commonly turn up in the same audit as an obsolete <marquee> element, on sites that haven’t had a structural accessibility pass in some time.
References
Frequently asked questions
Does marquee still work in current browsers?
Yes, unlike blink, most browsers still render marquee's scrolling behavior even though the element has been obsolete since HTML5 and is officially non-conforming markup. That is part of why it is still worth actively flagging: the failure is not a dead, silently-ignored tag, it is a live one still causing the problem it was deprecated for.
What's the difference between marquee and blink for this WCAG check?
Both map to the same 2.2.2 Pause, Stop, Hide criterion and share the same fix principle (no uncontrolled auto-moving content over five seconds), but marquee scrolls text horizontally or vertically while blink toggles visibility. See blink for the flickering variant of this same underlying failure.
Can marquee be made accessible by adding scrollamount or behavior attributes?
No. Marquee's own attributes control scroll speed and direction, not user control: none of them add a pause, stop, or hide mechanism. There is no attribute combination that makes the native element satisfy 2.2.2; it has to be replaced with a custom-built, controllable alternative.
Does a CSS-only scrolling ticker have the same problem as marquee?
Yes, if it scrolls automatically with no pause control and runs longer than five seconds. The element markup does not matter to WCAG 2.2.2: a div animated with CSS keyframes that scrolls continuously fails for the identical reason marquee does, unless it includes a working pause, stop, or hide control.
Is marquee content read aloud correctly by screen readers?
Inconsistently. Screen reader behavior around marquee varies, and some announce the scrolling text repeatedly or in fragments as it updates, which is a separate problem from the visual scrolling issue this rule documents, and one more reason to replace it with a static or properly-controlled alternative.