the last (accessible) carousel you'll ever need
A fully accessible, WCAG 2.0 / 2.1 compliant, drop-in replacement for Slick Slider (1.8.1) intended to make life easier for real-world dev teams who need to pass accessibility audits.
This package implements accessibility and usability improvements crafted and tested by native screen reader users, low vision users, and expert accessibility consultants at Accessible360 based on their experiences helping to make hundreds of carousels accessible for clients around the world. Read on to learn more about why this package exists, its features, how to use it, and how you can get involved!
Also check out this collection of ready-to-use demos on CodePen for common scenarios like hero banners, scrolling product cards, PDP thumbnail images, and more!
Example using jsDelivr
Just add a link to the CSS file in your
<!-- Add the core slick.min.css --> <link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/npm/@firstname.lastname@example.org/slick/slick.min.css"> <!-- Add ONE of the theme files (accessible version or original) --> <link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/npm/@email@example.com/slick/accessible-slick-theme.min.css"> <link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/npm/@firstname.lastname@example.org/slick/slick-theme.min.css">
Then, before your closing
<body> tag add:
npm install accessible-slick
Why is this needed?
Almost by design, carousels are pretty hard for screen reader users (especially newbies) to understand and interact with successfully, let alone enjoy. Its hard to know where slides begin and end, how the slide navigation dots work, or where the various controls are. Carousels also vary quite a bit between sites or even just between pages, so it can be difficult for screen reader users to build up a reliable mental model that applies to ALL carousels. And let's not even get started on autoplay functionality (WCAG 2.2.2, anyone?)!
As one of the most widely used carousel packages out there, Slick Slider has many of these same accessibility issues, making it a consistent source of frustration for dev teams when they go through an accessibility audit. Efforts have been made in the Slick Slider repo to improve these issues (especially in version 1.8.1), but those efforts have also introduced new accessibility issues too!
In the long term it'd be great to contribute some improvements to the core Slick Slider repo, but that may or may not be possible considering it's been abandoned (but not deprecated) by it's original author since 2016. A maintainer or two has recently stepped up to resume development, but with over 1,000 open issues and nearly 200 open PRs (some with conflicting approaches), its unlikely that the big fixes needed will make their way to the master branch any time soon.
In the short term, we're releasing our take on an accessible Slick Slider implementation as a fork that respects the original functionality and API features as much as possible so you can improve the accessibility of your carousels right now! We'll make it available through all the same channels (like NPM and jsDelivr) so upgrading is as easy as changing the URLs in your
What makes this accessible?
This package implements the following changes, all of which have been thoroughly tested and discussed with Accessible360's team of native screen reader users, low vision users, and experienced accessibility engineers:
Wrapper now has
||Tells screen reader users exactly where the carousel begins and ends in the DOM and gives them a landmark they can jump to or skip easily. Use the
Each slide now has
||Tells screen reader users exactly where each individual slide begins and ends in the DOM. It should fit the vast majority of use cases, but if you really want to disable it you can do so with the new
|Enabling autoplay now automatically adds a pause/play toggle button as the first focusable element (with customizable icons!).||WCAG 2.2.2 requires that all auto-updating content comes with a way to pause, stop, or hide it. For carousels, pause/play icon buttons are the most familiar option. Since autoplay is so disruptive for keyboard and screen reader users, as well as people with certain cognitive conditions, the button is the very first piece of content in the slider so it can be reached right away.|
|Instructions can now be provided for screen reader users||If your slider uses complex logic or unconventional interaction behaviors, there is a good chance that screen reader users will have an especially hard time figuring it out. If you're using the
|The Previous and Next arrows can now be placed before, after, or on either side of the slides in the DOM to match the visual design.||Designers can get really creative with sliders sometimes, making it difficult to ensure that all of the controls and slide contents are in a logical order in the page's DOM (WCAG 1.3.2) and tab sequence (WCAG 2.4.3). Using the new
|A more accessible CSS theme is now available with better focus styles and larger icons.||The original CSS theme (
|When Center Mode is enabled, the
||As shown in the original examples, it is possible to apply custom styles to the centered slide to emphasize it. Since it's not possible to determine when this is done, the safest option is to just always tell screen reader users which slide is the centered one.|
|Previous and Next button markup improved to use less ARIA and to safely hide the icons from screen readers.||Per the First Rule of ARIA Use,
|Tab markup is no longer used for slide dots or slides.||Carousels don't look like tabs, so real users wouldn't expect them to work like tabs, especially when there are multiple slides visible at a time.|
|Keyboard navigation with the
|When slides are dynamically added after initialization, they will now automatically get
||The API expects you to supply the complete markup for each slide you add, including its wrapper. However, developers may not realize that they need to add these attributes for accessibility, so adding them automatically guarantees they're there. This also ensures backwards compatibility with any existing implementations.|
All of the original events and methods, and most of the original settings, are still available and work as expected, so your existing configurations won't need to be updated at all! Refer to the original Slick Slider documentation to see how to use them:
In addition the original functionality, the following new settings have been added:
|arrowsPlacement||string ('beforeSlides' | 'afterSlides' | 'split')||null||Determines where the previous and next arrows are placed in the slider DOM, which determines their tabbing order. Arrows can be placed together before the slides or after the slides, or split so that the previous arrow is before the slides and the next arrow is after (this is the default). Use this setting to ensure the tabbing order is logical based on your visual design to fulfill WCAG 1.3.2 and 2.4.3.|
||Instructions for screen reader users placed at the very beginning of the slider markup. If you are using
|pauseIcon||string (html | jQuery selector) | object (DOM node | jQuery object)||
||Custom element to use as the "pause" icon inside the autoplay pause/play toggle button, when
|playIcon||string (html | jQuery selector) | object (DOM node | jQuery object)||
||Custom element to use as the "play" icon inside the autoplay pause/play toggle button, when
|regionLabel||string||'carousel'||Text to use for the
|useAutoplayToggleButton||boolean||true||Controls whether a pause/play icon button is added when autoplay is enabled. Setting this to
The following settings have been removed from the API, but if you pass them in through your initialization function or data attributes nothing bad will happen! If any of these settings are passed in, you'll just get a soft console warning letting you know that the setting is no longer relevant.
|accessibility||Equal access should not be a feature that can be turned off. This setting actually made the slides less accessible by introducing unintuitive tab markup, keyboard navigation that conflicts with screen readers, and more. See issue #12.|
|focusOnChange||Per WCAG 3.2.2 and user research, keyboard focus should never be moved unless the user is told ahead of time. Even when explained, moving focus like this would suck for keyboard users, so this setting had to go. See issue #11.|
|focusOnSelect||Unnecessary since keyboard navigation has been removed. Even with keyboard navigation, tab stops on non-actionable elements is very strange for keyboard users, and really just adds work for them. See issue #11.|
If you'd like to contribute changes or just make modifications for your own use, use the following process:
- Install all the dev dependencies with NPM:
Make your changes to the source files. You'll want to focus on:
Build! Multiple build systems are available to help with future-proofing. Use whichever one you like - the output is the same!
# Build with Gulp (see gulpfile.js) gulp # OR build with Grunt (see gruntfile.js) grunt
- Check your changes by loading up
docs/index.htmlin your browser.