Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

Accessibility · WCAG 2.2.2 level A

Marquee Elements Are Deprecated: Replace Uncontrolled Scrolling

Replace obsolete marquee elements with readable content. If motion remains, provide usable controls, respect reduced motion, and review actual behaviour.

Published · Updated

What the check tests

Check
a11y.axe.marquee - <marquee> elements are deprecated and must not be used
Passes when
Ensure <marquee> elements are not used
Scope
graded on every page crawled
Conformance
WCAG level A
Fix effort
small - under an hour

In one paragraph

Marquee elements are deprecated and must not be used identifies obsolete scrolling-content markup in the supplied rule. Replace it with a static message where possible, preserving all useful information. If automatic motion remains, review its duration, parallel content, essential purpose, and user controls under the relevant requirements. Switching from an obsolete tag to CSS does not automatically make the experience accessible.

Why it matters

Scrolling announcements can be difficult to track and can distract from other tasks. WCAG 2.2.2 sets conditions for pausing, stopping, or hiding automatically moving, blinking, or scrolling information lasting more than five seconds alongside other content, with an essential-activity exception.

Auto-updating information has a related but distinct part of the same criterion without a universal five-second exemption. Do not treat every ticker as safe simply because one animation iteration is short or resets repeatedly.

The obsolete marquee tag and the actual behaviour need separate evaluation. A controlled or static implementation can differ from the historical default, while a custom CSS slider can recreate the same barrier without using the tag. Automated element detection does not decide every applicable WCAG condition.

How WebAuditOS evaluates this finding

The supplied axe rule reports visible marquee elements and maps serious impact to high severity. Hidden or off-screen instances do not produce the same finding under its documented visibility logic. It runs on rendered sampled states rather than every possible interaction.

A separate compatibility check can find obsolete source markup regardless of visibility. Neither check evaluates every CSS animation, carousel, or control. The source's rule impact should not be presented as proof that each instance has identical real-world motion or that unreported animation is acceptable.

How to fix it

  1. Locate the actual tag and the content source. Check templates, CMS widgets, third-party components, and runtime output. Determine whether scrolling is truly required for the message.
  2. Prefer static readable text when it serves the task. For example:
<p class="announcement">See the updated delivery schedule before ordering.</p>

Use the real message and ensure narrow layouts do not clip information that previously scrolled through view.

  1. Remove obsolete markup while preserving links, emphasis, and intended reading order. Do not discard important notices merely because their old presentation was problematic.
  2. If a moving component remains justified, implement persistent usable controls. A labelled native pause or stop button should work with keyboard and touch, and the stopped state should allow the user to continue using the rest of the page.
  3. Treat hover and focus pausing as optional support, not the sole control. A mechanism requiring the user to keep focus parked on the ticker can prevent other tasks and does not meet the intended independent pause behaviour.
  4. Respect reduced-motion preferences with a suitable alternative. This complements rather than universally replaces the applicable pause or stop requirement. Review essential-motion exceptions carefully instead of assuming all branding is essential.
  5. If content is duplicated for a seamless visual loop, keep redundant copies out of assistive output without hiding the sole meaningful version or leaving hidden focusable links. Test actual interaction and announcements.
  6. Rescan the obsolete-element checks and manually evaluate motion, automatic updates, focus, and responsive layouts. A CSS replacement needs its own review even if the original rule no longer applies.

What the fix can break

Static content may wrap into more lines than an animated bar allowed. Redesign the space rather than truncating a message that has no other accessible version.

Duplicate loop content can create repeated links or speech. Avoid adding aria-hidden to a subtree containing controls that users can still focus.

Do not replace an inert or rarely visible legacy widget with a constantly moving modern one without a clear benefit and tested controls. Technological modernity is not an accessibility result.

Questions

Is a CSS ticker automatically allowed?

No. Evaluate actual movement, updates, controls, duration, and the relevant exceptions.

Does pausing on hover work for everyone?

No. Provide a suitable mechanism for keyboard and touch use, and let users move on while content stays paused where required.

Why did only the compatibility check report a hidden tag?

The supplied checks use different source and visibility scopes. That difference does not certify the whole widget.

Review obsolete HTML, blink elements, and the automation limits guide.

What severity does this get in the report?

High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core 4.13.0, so a failure arrives as high - which is why the panel above states a conformance level rather than a severity.

Standards and sources

In the report

Test this on your own site

Every scan runs a11y.axe.marquee on every page it crawls, on every plan. The finding carries this id, so a line in a report can be matched to the explanation above - and the free scan needs no account.