Accessible Carousel Library Comparison

Scores re-fetched 2026-06-07 from isitaccessible.dev. Local WCAG 2.1 AA and W3C pattern audits run against this site’s own implementations on the same date.

Two numbers, two meanings. The score below is isitaccessible.dev’s measure of how many accessibility-related GitHub issues a library has closed — a signal about the library’s maintenance, not your markup. Our audit runs axe-core and the W3C carousel checks against the actual implementations on this site (with workarounds applied). They diverge: several low-scoring libraries pass our audit because the right ARIA was added by hand. Read the score as “how much will the library fight you”, and the audit as “what’s achievable once you’ve done the work”.

Contents

• TL;DR Recommendation

  • CSS Class Name Customization
  • Libraries Not Included

• Acceptance Criteria for Accessible Carousels

  • WCAG Success Criteria
  • Keyboard Navigation
  • Auto-Rotation / Autoplay
  • Screen Reader Support
  • ARIA Implementation
  • Visual & Design
  • Content & Structure
  • Testing Checklist

• Common A11y Issues and Fixes

  • Common issues
  • Our fixes

• CSS-Only Carousels (Future)

• References

  • Standards & Guidelines
  • Analysis & Articles
  • Implementation Resources

• Conclusion

TL;DR Recommendation

Embla Carousel is the clear winner for accessibility-focused projects.

*Wrap = wrapper needed

CSS Class Name Customization

Some libraries let you use your own class names (e.g., Tailwind utilities), while others require their fixed classes.

Libraries Not Included

These libraries were considered but not implemented or tested on this site. They are listed for reference, not scored as if covered.

jQuery-dependent (require jQuery):

If you must use jQuery, accessible-slick is the recommended choice as it was specifically designed for accessibility.

Other (not implemented here):

Acceptance Criteria for Accessible Carousels

Derived from W3C WAI, ARIA APG, and expert resources. Use this checklist when evaluating or building carousels.

WCAG Success Criteria

Keyboard Navigation

• Tab key moves focus to/through interactive carousel elements
• Tab does not trap — after last focusable element, focus moves to next page element
• Arrow keys navigate between slides (when carousel is focused)
• Enter/Space activates focused controls (buttons, links)
• Escape stops auto-rotation (if applicable)
• No infinite Tab loops — user can always Tab out of carousel
• Hidden slides are not focusable — off-screen content removed from tab order

Auto-Rotation / Autoplay

• Pause/Play button provided — visible, keyboard accessible
• Rotation stops on keyboard focus — entering carousel halts movement
• Rotation stops on hover — mouse over carousel pauses it
• Rotation stops on interaction — clicking controls halts movement
• Explicit action to restart — rotation doesn’t auto-resume
• No auto-rotation preferred — static carousels are more accessible
• If autoplay, minimum 5 seconds — adequate time to read content

Screen Reader Support

• Carousel has accessible name — aria-label or aria-labelledby
• Carousel role is announced — aria-roledescription="carousel"
• Slides have accessible names — “Slide 1 of 5” pattern
• Slide changes are announced — aria-live="polite" region
• Live announcements disabled during auto-rotation — prevents constant interruptions
• Hidden slides are hidden from AT — aria-hidden="true" or inert
• Controls have accessible names — “Previous slide”, “Next slide”, “Go to slide 3”
• Current state is communicated — aria-current, aria-selected, or aria-disabled

ARIA Implementation

Carousel Container:

• role="region" or role="group"
• aria-roledescription="carousel"
• aria-label="[Descriptive name]"

Individual Slides:

• role="group"
• aria-roledescription="slide"
• aria-label="[N] of [total]" or similar

Navigation Controls:

• Previous/Next buttons have descriptive aria-label
• Dot/pagination buttons indicate target slide
• Current slide’s control marked with aria-disabled="true" or aria-current="true"

Rotation Control:

• Dynamic aria-label reflects state (“Stop rotation” / “Start rotation”)
• Positioned as first focusable element in carousel

Visual & Design

• 3:1 minimum contrast ratio for controls and indicators
• Visible focus indicators — clear outline on focused elements
• Non-color focus indication — border, outline, or shape change
• Adequate touch target size — minimum 44x44px
• Current slide indicator uses more than color alone
• Critical content not only in images — text alternatives provided

Content & Structure

• Semantic HTML — use <button>, <section>, lists where appropriate
• Logical DOM order — controls before slides in source
• Skip link provided — allow users to bypass carousel
• Maximum 5 slides — limit cognitive load
• Each slide has clear purpose — meaningful content, not just decoration
• Links and CTAs are clear — not just “Learn more”

Testing Checklist

• Keyboard-only testing — navigate entire carousel without mouse
• Screen reader testing — VoiceOver (macOS/iOS), NVDA/JAWS (Windows), TalkBack (Android)
• Zoom testing — 200% and 400% zoom levels
• Reduced motion testing — prefers-reduced-motion honored
• High contrast mode testing — Windows High Contrast Mode
• Axe/Lighthouse audit — automated accessibility testing
• Manual WCAG review — against 2.1 AA criteria

Common A11y Issues and Fixes

Recurring issues across carousel libraries, plus how we address them in this demo. For library-specific notes and implementation details, see each carousel page:

• Embla
• Flicking
• React Responsive Carousel
• Siema
• Swiper
• Flickity
• Keen Slider
• tiny-slider
• React Slick
• Splide
• Glide.js

Common issues

• Hidden slides remain in the tab order
• Missing or incorrect ARIA attributes
• Focus management on slide change
• Pagination dots not keyboard accessible

Our fixes

• Focus trap prevention via tabindex management
• Custom pagination with proper aria-label and aria-current
• Controls positioned below the carousel (consistent, accessible)
• Screen reader announcements via aria-live regions (Embla plugin)

CSS-Only Carousels (Future)

Chrome is developing native CSS carousel features with built-in accessibility:

• Proper ARIA roles handled by browser
• Keyboard navigation built-in
• Screen reader support automatic
• scroll-state() container queries for managing inert content

Status: Experimental. Sara Soueidan’s analysis notes current CSS carousels fail accessibility criteria and are unsuitable for production.

References:

• Chrome DevRel: Carousels with CSS
• Sara Soueidan: CSS Carousels Accessibility

References

Standards & Guidelines

• W3C WAI Carousel Tutorial
• ARIA APG Carousel Pattern
• Universal Design IE: Make Carousels Accessible

Analysis & Articles

• isitaccessible.dev — Package accessibility scoring
• Smashing Magazine: Guide to Building Accessible Carousels
• A11y Collective: Accessible Carousel
• a11y-101: Carousels
• Sara Soueidan: CSS Carousels Accessibility

Implementation Resources

• Accessible Carousel Boilerplates
• Chrome DevRel: Accessible Carousel

Conclusion

Use Embla Carousel with its accessibility plugin for the best out-of-box accessibility:

• Highest accessibility score (100%)
• Dedicated, well-documented accessibility plugin
• Supports vanilla JS and React natively (no wrapper needed)
• Fast issue resolution (12.6 day median)
• Implements proper ARIA live regions for screen reader announcements

Installation:

# Vanilla JS (requires v9 RC for accessibility plugin)
npm install embla-carousel@9.0.0-rc02 embla-carousel-accessibility@9.0.0-rc02

# React (requires v9 RC for accessibility plugin)
npm install embla-carousel-react@9.0.0-rc02 embla-carousel-accessibility@9.0.0-rc02

Note: The accessibility plugin only supports Embla v9 (release candidate), and the three packages must stay on the same rc version (they peer-depend on each other exactly). The stable v8.x is incompatible with the accessibility plugin, so do not “upgrade to latest” — npm’s latest tag points at 8.x.

Always test with:

• Keyboard navigation (Tab, Arrow keys, Enter, Escape)
• Screen readers (VoiceOver, NVDA, JAWS)
• Automated tools (axe, Lighthouse)
• Real users with disabilities when possible