Skip to content
BFSG compliance since 2025
Practice & implementation

Accessible Sliders: Carousels Without Barriers

Auto-rotating carousels violate WCAG 2.2.2 and lock out keyboard and screen reader users. How to make sliders accessible with pause, keyboard and ARIA.

12 min read KarussellPause Stop HideTastaturnavigationWCAG 2.2Slider

The rotating carousel on the home page is one of the most popular components on the web and at the same time one of the most problematic. It promises to fit several messages into a small area, yet the usage data are sobering: a widely cited analysis by the University of Notre Dame found a click-through rate of just 1% (University of Notre Dame) across all slides, and 89% (University of Notre Dame) of that went to the first slide alone. More serious is the accessibility picture. A carousel that advances by itself takes control of the page away from people, overwhelms them cognitively and effectively locks out keyboard and screen reader users. Among those affected are the roughly 1.2 million (DBSV) blind and visually impaired people in Germany. The good news about this starting point: a carousel need not be a barrier. Built correctly, it is operable, calm and WCAG-compliant. This guide shows where auto-rotating sliders fail, what WCAG 2.2.2 requires and how a WCAG audit assesses existing carousels and makes them fixable.

Key takeaways

  • Auto-rotation is the core problem: motion that starts automatically, lasts more than five seconds and runs in parallel with other content must, under WCAG 2.2.2 (Level A), be pausable, stoppable or hideable (W3C, WCAG 2.2).
  • Carousels barely work: the click-through rate is around 1% (University of Notre Dame) across all slides, 89% (University of Notre Dame) of that on the first - few people ever see the later slides.
  • Keyboard operability is mandatory: previous and next controls, the pause button and the slide dots must be reachable with Tab, operable with Enter or Space and given a visible focus (WCAG 2.1.1, 2.4.7).
  • Screen readers need structure: without clear labels, a live region and a role description, a carousel is an impenetrable jumble of changing content for assistive technology.
  • Motion itself can harm: automatically starting animation can trigger discomfort in cases of vestibular sensitivity; the system setting for reduced motion must be respected.
  • Less is often more: given 1% (University of Notre Dame) interaction, it is worth asking before any repair whether a static offer or a manually operated slider is the better component.

Why Auto-Rotating Carousels Lock People Out

The fundamental problem with an automatically rotating carousel is the removal of control. The page moves without the user having triggered it, and it moves to a rhythm someone else has set. For many people this is simply annoying. For some it is a genuine barrier. Anyone who reads more slowly - because of a cognitive impairment, a vision impairment or simply a foreign language - has often not grasped a slide before it jumps on. Anyone sensitive to motion may develop nausea or dizziness from the constant animation. And anyone operating the page with a keyboard or a screen reader loses their bearings at every slide change, because the content shifts out from under their own access.

On top of this comes the poor effect. The University of Notre Dame analysis mentioned above stands for a whole series of studies that attribute low engagement to the carousel. The Nielsen Norman Group likewise concludes that automatically forwarding carousels annoy users rather than inform them and reduce the visibility of the individual pieces of content (Nielsen Norman Group). The motion draws attention, but instead of inviting reading it is often classified as advertising and tuned out. A component that generates hardly any interaction while at the same time locking people out deserves a critical look before it is laboriously repaired. This is exactly where our services begin: first check whether the carousel serves the goal, then implement it accessibly.

Motion is not neutral

An automatically starting slider makes a decision for all visitors at once: that motion is wanted. For people with vestibular sensitivity, attention disorders or a slower reading pace, this assumption is wrong. Accessibility here means handing control back rather than pre-empting it.

What WCAG 2.2.2 Actually Requires

Success criterion 2.2.2 Pause, Stop, Hide sits at the lowest conformance level, that is Level A, and is therefore a baseline rather than an add-on. The rule is clearly defined: for any moving, blinking or scrolling information that starts automatically, lasts more than five seconds and is presented in parallel with other content, there must be a mechanism to pause, stop or hide it (W3C, WCAG 2.2). For automatically updating information the same applies by analogy, with the added option to control the update frequency. The only exception concerns motion that is essential to the activity itself, such as a loading indicator.

A typical home page carousel meets all three conditions: it starts without action, changes slides at short intervals well beyond the five-second threshold and runs in parallel with text, navigation and other elements. That makes the pause, stop or hide function not optional but mandatory. In practice, the clean solution is a clearly visible pause control that fully halts the rotation and does not resume it after a short while. The article on the new criteria of WCAG 2.2 explains how this criterion fits into the current rulebook and which requirements were added in 2023.

Pause

A visible control halts the rotation. It must not restart on its own and should clearly indicate its state so the motion stays at rest for good (WCAG 2.2.2).

Keyboard

All controls are reachable with Tab and triggerable with Enter or Space. No element may trap the focus (WCAG 2.1.1, 2.1.2).

Visible focus

The keyboard focus must be clearly recognizable. An invisible focus makes the previous, next and pause controls effectively unusable (WCAG 2.4.7).

Screen reader

A label, a role description and a polite live region ensure that slide changes are announced comprehensibly instead of happening unnoticed.

Target size

Tiny arrows and dots are hard to hit. The new WCAG 2.2 recommends operable targets of at least 24 by 24 CSS pixels (W3C, WCAG 2.2).

Calm motion

Transitions should be subtle and respect the system setting for reduced motion, so that no one feels dizzy.

These six requirements show that accessibility in a carousel is not a single switch but an interplay. The pause function satisfies WCAG 2.2.2, yet it is useless if the control cannot be reached with the keyboard or the screen reader does not announce it. Conversely, the best label does not help if the motion keeps running and pulls the content out from under the finger. Only the interplay of control, operability and announcement makes the component usable.

Keyboard Operation: Reachable, Triggerable, Visible

A large share of users operate the web entirely without a mouse, whether permanently due to a motor impairment, temporarily after an injury or simply by habit. For them, the keyboard decides between access and exclusion. An accessible carousel therefore makes sure that every interactive part appears in the tab order: the previous and next controls, the pause button and the slide dots, if they can be jumped to. Each of these elements must be triggerable with Enter or Space, and the current focus must be clearly visible at all times. A common mistake are arrows implemented as pure image links without a text alternative; they are worthless to keyboard, screen reader and search engines alike. The WebAIM Million Report 2026 counts empty links among the most common errors and found them on 46.3% (WebAIM Million, 2026) of the home pages analyzed.

It is also important that the carousel does not trap the focus. Anyone tabbing through the slide controls must be able to leave the group just as they entered it, without getting stuck in an endless loop. The fundamentals of this operation are explored in the article on keyboard navigation in web development, which shows how focus order, visible focus and keyboard traps relate. For the detailed implementation, accessible web development is the right frame, because a carousel is only as good as the markup it stands on.

FeatureAuto-rotating sliderAccessible carousel
Start of motionstarts automatically, runs continuouslystarts on request or stays at rest
Pause functionnone or hiddenvisible, permanent, keyboard-operable
Keyboardarrows not reachableall controls operable via Tab and Enter
Focusinvisible or trappedclearly visible, freely exitable
Screen readerslide changes unannouncedrole description and polite live region
Target sizetiny dots and arrowsat least 24 by 24 CSS pixels

The pause control is not a detail

A clearly visible, keyboard-operable pause control satisfies WCAG 2.2.2 and hands control back to every visitor. It should fully halt the rotation and not resume by itself after a few seconds, because otherwise the control is only borrowed and not truly given.

Screen Readers: Structure, Role and Announcement

For screen reader users a carousel is especially tricky, because its content changes without the motion being perceptible. A slide change that is seen visually as an animation is, to assistive technology, at first only a silent swap of text. Without additional information this feels like jumping content whose cause stays in the dark. Three building blocks help: a clear role description that identifies the component as a carousel, meaningful labels for all controls and a polite live region that announces the change of the active slide in a calm tone without interrupting the ongoing reading. How these roles and live regions work together is explained in detail in the article on ARIA roles, states and live regions.

Equally important is that non-visible slides are also not reachable for the screen reader. If all slides sit in the code simultaneously and are merely hidden visually, assistive technology may read out content no one sees, along with links that seem to lead nowhere. Only the active slide should be in scope, the rest are taken out of the reading order. How to structure a page as a whole for speech output is explored in the article on screen reader optimization for a website. Only when structure, role and announcement fit together does the slide change turn from a silent jolt into a comprehensible action.

  • A role description clearly identifies the component as a carousel
  • Previous, next and pause controls carry meaningful, visible labels
  • A polite live region announces the change of the active slide without interrupting
  • Only the active slide is in scope, the rest are taken out of the reading order
  • Slide dots show the total count and the current position, such as slide 2 of 4
  • The visible label and the programmatic name match on every control

Reduce Motion Instead of Forcing It

Even a carousel with a pause control starts out in motion, and it is precisely this first moment that can burden people with vestibular sensitivity. That is why a clean implementation includes respecting the system setting for reduced motion. Anyone who indicates in their operating system that motion should be avoided where possible should get a carousel that does not auto-rotate in the first place but stays still and only reacts to operation. In this case the transitions between slides can be reduced to a gentle fade or switched off entirely. How to design animation in a WCAG-compliant way without sacrificing effect is covered in the article on reduced motion and accessible animations.

Reducing motion does not mean giving up on design. A calm, manually operated carousel can be just as visually appealing as a rotating one, but it gains in accessibility and often in effect too, because the content no longer runs away. This attitude matches a principle we implement again and again in our reference projects: design and accessibility are not opposites but two sides of the same careful work.

Default state: still

An accessible carousel is at rest in its default state and moves only when someone triggers it, or it respects switched-off motion from the outset. This turns a component that takes control into one that gives control, without the design suffering for it.

Check, Repair or Replace

The practical path begins with an honest inventory. An automated scan reliably uncovers many machine-detectable errors, such as missing labels, empty links or insufficient contrast. But whether a pause control actually halts, whether the focus is visible and whether the slide change is announced sensibly only shows in manual testing with keyboard and screen reader. This combination of automated and manual work is the core of a solid WCAG audit, which checks every existing carousel against criteria 2.2.2, 2.1.1 and 2.4.7 and delivers a prioritized list of the necessary corrections. The overarching frame for this are the BFSG requirements, which have applied since 28 June 2025 (Bundesfachstelle Barrierefreiheit) to large parts of digital consumer business.

In many cases the best answer is not repair but replacement. If a carousel generates only 1% (University of Notre Dame) interaction anyway, a static area with the most important message is often more effective and accessible at the same time. Where several pieces of content genuinely need space side by side, a manually operated slider without auto-rotation can be the right choice, complemented by clearly worded text. How to prepare content so that it works without the pressure of motion is shown in the article on plain language for understandable web texts. And anyone who wants to solve carousels, sliders and similar components cleanly once and for all will find in the accessible design system the systematic way to build each component right the first time.

A carousel must serve people, not the home page. The moment it moves by itself and asks no one, it has taken the control that really belongs to the visitor.

Principle from the audit practice of accessible web development

The legal and economic frame underlines the urgency. While 95.9% (WebAIM Million, 2026) of the home pages analyzed carry detectable WCAG failures and the average page reaches 56.1 (WebAIM Million, 2026) individual errors, many digital consumer offerings have been obliged to be accessible since 28 June 2025 (Bundesfachstelle Barrierefreiheit). An auto-rotating carousel without a pause function is a visible, easily testable violation of a Level A criterion and thus an obvious starting point. Fixing it gains legal certainty, opens the page to the roughly 1.2 million (DBSV) blind and visually impaired people in Germany and, along the way, creates a calmer, clearer component that puts the content in the foreground rather than the motion.

This article is based on data from: the W3C Web Content Accessibility Guidelines (WCAG) 2.2, in particular success criteria 2.2.2, 2.1.1, 2.1.2, 2.4.7 and 2.5.8, the University of Notre Dame usability analysis of home page carousels, the Nielsen Norman Group analyses of automatically forwarding carousels, the WebAIM Million Report (2026), the figures from the German Association for the Blind and Visually Impaired (DBSV), the standard EN 301 549, and the information from the Bundesfachstelle Barrierefreiheit on the German Accessibility Act (BFSG).

Related Articles