Touch Targets, Swipe Gestures, and prefers-reduced-motion: Carousels for All Input Devices

The web carousel is the most prominent misunderstanding in mobile web design: found on almost every screen, yet usually a broken UX component on smartphones. While users intuitively swipe rather than click, most sliders ignore mobile realities entirely. Genuine swipe gestures, accessible touch targets, and the prefers-reduced-motion media query are simply forgotten in technical implementations — a digital blind spot at users' expense.

Swipe Without an Alternative

A swipe gesture is, by definition, a path-based interaction — not just the start and end point matter, but the entire movement. This means: every function reachable via a path-based gesture must also be triggerable via a simple click or tap.

For a carousel, that means: swipe alone is not enough. Previous/Next buttons are not an optional extra — they're the accessible baseline requirement.

<!-- HTML -->
<div class="carousel" style="touch-action: pan-y;" />

/* CSS */
.carousel { touch-action: pan-y; }

The CSS property touch-action: pan-y allows vertical scrolling within a container with horizontal scroll interaction. It's a frequently overlooked detail. Without it, the carousel either blocks scrolling or ignores the swipe gesture.

Touch Targets Too Small

Since WCAG 2.2 — specifically WCAG 2.5.8 — interactive elements must be at least 24 × 24 pixels, including the spacing to neighboring interactive elements. 44 × 44 pixels is the recommended target. The most common violation in carousels is the dot navigation.

Typical dot navigation dots are 8–12 pixels in size. Visually defensible, but for people with tremors, limited fine motor control, or on small touchscreens, simply too small to hit reliably. The solution isn't to make the dots bigger — it's to enlarge the clickable area via padding:

.dot {
  width: 10px;
  height: 10px;
  padding: 10px; /* tap area: 30×30px */
}

The dot stays visually small. The tap target is large enough.

Animations Without Consideration

Slide animations are unremarkable for most users. For people with vestibular disorders — an impairment of the sense of balance — moving content can trigger dizziness, nausea, or worse. For people with epilepsy, rapid visual changes can trigger seizures.

CSS has offered a system-wide solution for years: prefers-reduced-motion is a media query that applies when users have enabled reduced motion in their device's system settings. The browser distinguishes between two OS states: while prefers-reduced-motion: reduce actively signals that users have disabled animations system-wide (often due to dizziness or motion sickness) and web effects must stop, prefers-reduced-motion: no-preference represents the default state, in which all intended animations may run normally. Very few carousels respect this.

@media (prefers-reduced-motion: reduce) {
  .carousel-slides {
    scroll-behavior: auto;
    transition: none;
  }
}

Two lines of CSS. No JavaScript, no overhead. And the difference for affected users is significant.

What's Coming Next

Five parts, five error zones — semantics, keyboard, live regions, autoplay, touch. The complete picture is now in place. What remains is the question: does all of this really have to be built from scratch every time?

Part 6 introduces faceless-carousel: an open-source Web Component that implements everything from this series as accessible by design — without imposing any design decisions on the developer.

➔ Faceless UI: An open-source web component for accessible carousels

Sources: W3C APG, Carousel Pattern · WCAG 2.5.1, Pointer Gestures · WCAG 2.5.8, Target Size Minimum · Chrome, Accessible Carousel