When a screen reader should speak—and when it shouldn't: aria-live and autoplay

A11y semantics like aria-live are still missing far too often in web applications. Without these ARIA properties, a screen reader has no way of knowing when content changes. Users who have text read aloud receive no indication that a new slide has appeared.

For carousels with auto-rotation, there's one mistake made so frequently it's almost become the standard.

The Concrete Requirement

Auto-rotating content that runs for longer than five seconds and is displayed alongside other content must have a mechanism to pause or stop it. That's WCAG 2.2.2, Level A — not an optional recommendation.

For a carousel with autoplay, this translates to four concrete requirements:

The Play/Pause button also needs a label — dynamically updated via JavaScript — that describes the current state, not the action:

<!-- Rotation running -->
<button aria-label="automatic rotation active">⏸</button>

<!-- Rotation stopped -->
<button aria-label="automatic rotation stopped">▶</button>

This sounds like a detail. For screen reader users, it's the difference between "I know what's happening" and "I don't know if my click did anything."

Announcements

The ARIA attribute aria-live defines live regions in HTML to notify screen readers of dynamic content changes in an accessible way. When and with what priority the announcement happens is controlled through the values polite and assertive.

<!-- Auto-rotating carousel -->
<div class="slides" aria-live="off" aria-atomic="false">
  <!-- Slides -->
</div>

<!-- Manually controlled carousel -->
<div class="slides" aria-live="polite" aria-atomic="false">
  <!-- Slides -->
</div>

aria-live="polite" is used to announce changes when users are not actively interacting. The most common mistake: it's applied across the board, including for autoplay. That means the screen reader announces new content with every automatic slide change. Every few seconds. In the middle of whatever the user is currently reading. That's not an accessible carousel — that's auditory chaos.

aria-live="off" disables screen reader announcements for DOM changes. The correct logic is therefore: when rotation is running, aria-live is off. When the user navigates manually, it switches to aria-live="polite". This means the value must be toggled dynamically via JavaScript between both states — tied to the Play/Pause button.

aria-atomic="false" instructs the screen reader to read out only the changed portion of the container, not the entire content. With aria-atomic="true", after every slide change the complete container would be read from scratch: slide position, title, description, link — everything at once.

Paginated Carousels

Another special case: carousels that display multiple slides at once. When three new slides simultaneously enter the visible area during a transition, aria-live="polite" results in three simultaneous announcements — confusing and uncontrollable.

For paginated carousels, Chrome Developers recommends leaving aria-live out entirely and relying on focus management instead: the screen reader learns of the change because the user actively navigated, not because a live region fired.

A UX Argument Worth Knowing

Building accessible websites sometimes also means questioning bad design decisions. Autoplay is one of them.

The Nielsen Norman Group has shown in multiple studies that automatically rotating carousels are disproportionately ignored by users — because the movement is unconsciously associated with advertising banners. At the same time, it distracts from the rest of the page. The paradox: autoplay makes important content less visible, not more.

Autoplay is therefore almost always the wrong decision. And that's not just an accessibility argument — it's a foundational UX point, independently confirmed by both the Nielsen Norman Group and web.dev. Anyone still using autoplay should at least understand what they're giving up.

What's Coming Next

Live regions and autoplay are covered. What remains: physical interaction. How large do buttons need to be? How is a swipe gesture implemented accessibly? And how do you protect users from vestibular issues caused by animations? Part 5 answers these questions on touch targets, swipe gestures, and prefers-reduced-motion.

➔ Touch Targets, Swipe gestures & prefers-reduced-motion

Sources: W3C APG, Carousel Pattern · WCAG 2.2.2, Pause, Stop, Hide · Chrome, Accessible Carousel · Nielsen Norman Group, Auto-Forwarding · web.dev, Carousel Best Practices