Alpine.js Carousel Slider: Touch Support and Keyboard Navigation

1. Why Not Swiper.js on Hyva Sites

Swiper.js is the most popular carousel library on the web, and at 140 KB minified (without gzip) plus its own module system, also the heaviest. On a Hyva site that avoids jQuery and Knockout.js entirely and where the whole JavaScript budget for the critical path should stay under 50 KB, Swiper.js is an unacceptable dependency. On top of that, Swiper.js brings its own event system, which interferes with Alpine.js' reactive proxy system when both operate on the same DOM elements.

The real core problem is a different one, though: most product pages on Magento shops do not need a feature rich slider with a virtual DOM abstraction. What they need is navigating forward and backward, touch swipe on mobile devices, keyboard navigation for accessibility, and optionally auto-play. All of that can be built with Alpine.js in under 120 lines. The slider in this tutorial uses native CSS for transitions, Pointer Events for touch swipe, and Alpine directives for state. The result is a slider with no external dependency that works on every device and does not trigger a single additional network request.

2. Building Carousel State with Alpine.js

The core of the carousel is a simple state object with a single reactive value: the current index. Every other state, whether a forward or backward button is disabled, which pagination dot is active, whether the live region should announce the new slide, is derived from this index. That is the central Alpine pattern: keep a minimal piece of state and compute all UI states from it. No duplicate state that needs manual syncing.

The slide elements themselves are not managed by Alpine, they are static HTML. Alpine only tracks the index and shows or hides slides with :class="{ hidden: currentIndex !== index }". That is deliberately simple: no virtual DOM nodes, no x-for, which can cause race conditions with scroll positions or transition timing. The transition is driven purely by CSS transition-opacity and transition-transform, which the browser handles natively and efficiently on the compositor thread.

// Alpine.js Carousel - minimal reactive state
function carousel(totalSlides, options = {}) {
  return {
    current: 0,
    total: totalSlides,
    autoPlayInterval: null,
    paused: false,

    get canPrev() { return this.current > 0; },
    get canNext() { return this.current < this.total - 1; },

    prev() {
      this.current = this.current > 0
        ? this.current - 1
        : options.loop ? this.total - 1 : 0;
      this.announce();
    },
    next() {
      this.current = this.current < this.total - 1
        ? this.current + 1
        : options.loop ? 0 : this.total - 1;
      this.announce();
    },
    goTo(index) {
      this.current = Math.max(0, Math.min(index, this.total - 1));
      this.announce();
    },
    announce() {
      // Updates aria-live region - Alpine reacts to current change automatically
      this.$nextTick(() => {
        this.$refs.liveRegion.textContent =
          `Slide ${this.current + 1} of ${this.total}`;
      });
    }
  };
}

3. CSS Transitions Instead of JavaScript Animation

JavaScript based animations using requestAnimationFrame or setInterval run on the main thread and can be disrupted by other JavaScript work. CSS transitions and CSS animations, on the other hand, run on the compositor thread as long as they only animate opacity and transform, and they stay smooth even under JavaScript load. For a carousel slider those are exactly the two properties that need animating: opacity for fade transitions, transform for slide transitions.

The implementation is simple: all slides are absolutely positioned within the container. Each slide has transition: opacity 0.4s ease, transform 0.4s ease. The active slide is opacity-100 translate-x-0, the previous one is opacity-0 -translate-x-full, the next one is opacity-0 translate-x-full. Alpine sets the matching Tailwind classes via :class based on the relationship between current and index. No JavaScript animation, no GSAP, no requestAnimationFrame: the browser does all the work.

4. Detecting Touch Swipes with Pointer Events

Pointer Events are the modern replacement for Touch Events and Mouse Events: a single event handler works for mouse, touch, and stylus alike. That makes the swipe code considerably leaner than an implementation with separate touchstart, touchmove, and touchend handlers. The swipe logic is linear: on pointerdown the X coordinate is stored, on pointerup the difference is calculated. If it exceeds a threshold (typically 50px), the carousel moves to the next or previous slide.

Important: setPointerCapture on the element during the pointerdown event ensures that all following pointer events land on that element, even if the user moves their finger beyond the element's boundaries. Without pointer capture you lose the pointermove event as soon as the finger leaves the element, which causes fast swipes to break off. The touch-action: pan-y CSS property on the container allows normal vertical scrolling while preventing browser interventions during horizontal swiping.

// Touch/Pointer swipe detection - works for mouse, touch, and stylus
initSwipe() {
  let startX = 0;
  const THRESHOLD = 50; // px - minimum swipe distance

  this.$refs.track.addEventListener('pointerdown', e => {
    startX = e.clientX;
    this.$refs.track.setPointerCapture(e.pointerId);
  });

  this.$refs.track.addEventListener('pointerup', e => {
    const deltaX = e.clientX - startX;
    if (Math.abs(deltaX) < THRESHOLD) return;
    deltaX < 0 ? this.next() : this.prev();
  });

  // Prevent click events from firing after a swipe
  this.$refs.track.addEventListener('click', e => {
    if (Math.abs(e.clientX - startX) > THRESHOLD) e.stopPropagation();
  });
},

5. Keyboard Navigation with ARIA Roving Tabindex

For carousels, the ARIA Authoring Practices define the roving tabindex pattern: only the active slide control has tabindex="0", every other one has tabindex="-1". When the user switches to another slide via the keyboard, the new button receives tabindex="0" and is focused programmatically, while the old one gets tabindex="-1". This prevents keyboard users from having to tab through every single pagination dot; instead they navigate with arrow keys inside the carousel widget.

In addition, the navigation buttons (Previous, Next) must be reachable via keyboard. The actual slide content should only sit in the focus order for the active slide; inactive slides get the inert attribute or aria-hidden="true" so that tab does not lead through hidden links in an inactive slide. The inert attribute is the modern solution: it removes every element inside a container from the focus order and from the accessibility tree at the same time.

6. Auto-Play with Pause-on-Hover and Pause-on-Focus

Under WCAG 2.1 success criterion 2.2.2, auto-play in carousels is only allowed if the user can pause, stop, or slow it down. The minimum requirement is a visible pause control. Beyond that, WCAG technique G4 recommends automatically pausing auto-play whenever the mouse pointer is over the carousel (hover) and whenever an element inside the carousel is focused (focus). Both prevent a slide from changing while the user is trying to activate a link in the current slide.

The implementation uses Alpine's @mouseenter, @mouseleave, @focusin, and @focusout on the container. The @focusout.capture checks whether the new focus target is still inside the container (this.$el.contains(e.relatedTarget)) before auto-play is resumed. The auto-play setInterval is started in init() and cleaned up via clearInterval in destroy(). Alpine calls init() on mount and destroy() on unmount automatically, so no manual lifecycle management is needed.

// Auto-play with pause on hover and focus
startAutoPlay(interval = 5000) {
  this.autoPlayInterval = setInterval(() => {
    if (!this.paused) this.next();
  }, interval);
},

stopAutoPlay() {
  clearInterval(this.autoPlayInterval);
  this.autoPlayInterval = null;
},

// Called from @mouseenter and @focusin on container
pauseAutoPlay() { this.paused = true; },

// Called from @mouseleave and @focusout on container
resumeAutoPlay(e) {
  // For focusout: only resume if focus left the component entirely
  if (e?.type === 'focusout' && this.$el.contains(e.relatedTarget)) return;
  this.paused = false;
},

init() {
  this.startAutoPlay(5000);
  this.initSwipe();
},

destroy() {
  this.stopAutoPlay();
}

7. ARIA Roles and Live Region for Screen Readers

A carousel without ARIA adjustments is a black box for screen reader users. The container gets role="region" and aria-label="Image gallery" so screen readers can identify the widget. Each slide gets role="group" and aria-label="Slide 1 of 5", which gives users a sense of their position within the slideshow. Inactive slides get aria-hidden="true" so their content does not end up in the screen reader's virtual cursor.

For automatic slide changes, an aria-live region is essential. A hidden <div aria-live="polite" aria-atomic="true"> with the class sr-only receives a new text such as "Slide 2 of 5" on every slide change, and the screen reader reads it out once the user is not performing another action. aria-atomic="true" ensures the entire text is read as one unit rather than word by word. That is the cleanest way to communicate slide changes without moving DOM focus.

8. Pagination Dots and Thumbnail Navigation

Pagination dots are buttons, not links or divs. Each dot gets aria-label="Show slide 3" and aria-pressed="true/false". Alternatively, the entire dot navigation can be implemented as role="tablist" with role="tab" buttons if the slides conceptually behave like tabs. In most cases the simpler button variant is preferable, because the tab pattern requires more specific keyboard navigation (only arrow keys within the tablist).

Thumbnail navigation is an extension where small preview images control pagination instead of dots. The implementation is not fundamentally different: the thumbnails are buttons, @click="goTo(index)" navigates to the corresponding slide, :aria-current="current === index ? 'true' : 'false'" shows the active state. The active thumbnail gets a visual border via a Tailwind class bound to state through :class. For lazy loading the thumbnail images, the loading="lazy" attribute is the natural fit: a browser native solution without any JavaScript.

9. Alpine Carousel vs. Swiper.js Compared

Swiper.js undeniably offers more features: virtual slides for very long lists, CSS scroll snap integration, complex effects like cards and cube. For a standard product image slider or hero banner on a Hyva site, though, these features are never actually needed. The comparison shows where a custom Alpine implementation is clearly superior: bundle size, Hyva integration, and full control over ARIA.

The only area where Swiper.js clearly wins is virtual slides for very long lists (thousands of slides). That is a niche case, though: product galleries typically have 3 to 10 images, hero sliders 2 to 5 slides. For anything below that, the Alpine implementation is the better choice: faster to load, more accessible, and fully inside the Tailwind CSS system.

10. Summary

A production ready Alpine.js carousel slider requires more than just forward and backward buttons. Touch swipe via Pointer Events, keyboard navigation with roving tabindex, auto-play with WCAG compliant pause logic, and ARIA live regions for screen readers are not extras, they are prerequisites for a slider that works on every device and for every user. All of that can be built with Alpine.js without any external dependencies, and it fits seamlessly into Hyva themes and Tailwind CSS.

The decisive advantage over Swiper.js or Slick: zero additional JavaScript bytes, no conflicts with the Alpine lifecycle, and full control over markup and ARIA attributes. Anyone who implements the patterns described in this tutorial ends up with a slider that does not weigh down Core Web Vitals, satisfies WCAG 2.1 AA, and is fully styleable through Tailwind.

11. FAQ: Alpine.js Carousel Slider