the last (accessible) carousel you'll ever need
A highly 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!
https://accessible360.github.io/accessible-slick
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!
Just add a link to the CSS file in your <head>:
<!-- Add the core slick.min.css -->
<link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/npm/@accessible360/accessible-slick@1.0.1/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/@accessible360/accessible-slick@1.0.1/slick/accessible-slick-theme.min.css">
<link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/npm/@accessible360/accessible-slick@1.0.1/slick/slick-theme.min.css">Then, before your closing <body> tag add:
<script type="text/javascript" src="//cdn.jsdelivr.net/npm/@accessible360/accessible-slick@1.0.1/slick/slick.min.js"></script>npm install @accessible360/accessible-slickAlmost 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 <link> and <script> tags without having to even touch your existing JavaScript code!
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:
| Feature | Why |
|---|---|
Wrapper now has role="region" and a configurable aria-label. |
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 regionLabel setting to change the aria-label text (defaults to 'carousel'). |
Each slide now has role="group" with a generic, numbered aria-label. |
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 useGroupRole setting. |
| 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 asNavFor setting or any of the API methods/events, you should probably explain how your carousel works to screen reader users. |
| 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 arrowsPlacement setting, you can now control where the previous and next buttons are injected to better match the visual design! |
| A more accessible CSS theme is now available with better focus styles and larger icons. | The original CSS theme (slick-theme.min.css) had very small icons and poor focus indicators. Now an alternative theme is available (accessible-slick-theme.min.css) with larger icons and browser-default focus indicators. To minimize risk of possible breaking styling changes, this theme is opt-in. Just update your <link> reference to use it! Check out the demo page to see it in action. |
When Center Mode is enabled, the aria-label of the centered slide will now be appended with the text "(centered)". |
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. |
| Feature | Why |
|---|---|
| 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, aria-label has been removed in favor of inner screen-reader-only text. Also, the HTML5 disabled attribute is now used instead of aria-disabled for more consistency across all input modalities. Finally, the custom icons are attached to inner spans that are properly hidden from screen readers with aria-hidden. |
| 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 Left and Right arrow keys has been removed. |
The Left and Right keys are already used by screen readers for virtual cursor navigation, and other users have no reason to expect this functionality exists without visible instructions or clues. |
When slides are dynamically added after initialization, they will now automatically get role="group" and a numbered aria-label. |
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:
| Setting | Type | Default | Description |
|---|---|---|---|
| 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. |
| instructionsText | string | null |
Instructions for screen reader users placed at the very beginning of the slider markup. If you are using asNavFor or adding custom functionality with API methods/events, you probably need to supply instructions! |
| pauseIcon | string (html | jQuery selector) | object (DOM node | jQuery object) | <span class="slick-pause-icon" aria-hidden="true"></span> |
Custom element to use as the "pause" icon inside the autoplay pause/play toggle button, when autoplay is enabled. |
| playIcon | string (html | jQuery selector) | object (DOM node | jQuery object) | <span class="slick-play-icon" aria-hidden="true"></span> |
Custom element to use as the "play" icon inside the autoplay pause/play toggle button, when autoplay is enabled. |
| regionLabel | string | 'carousel' | Text to use for the aria-label that is placed on the wrapper. |
| useGroupRole | boolean | true | Controls whether role="group" and an aria-label are applied to each slide. |
| useAutoplayToggleButton | boolean | true | Controls whether a pause/play icon button is added when autoplay is enabled. Setting this to false without providing an alternative control would likely violate WCAG 2.2.2, so be careful! |
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.
| Setting | Reason(s) |
|---|---|
| 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:
npm install-
Make your changes to the source files. You'll want to focus on:
slick/slick.jsslick/slick.scssslick/slick-theme.scss
-
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.
See the contributing guidelines.
Massive kudos to Ken Wheeler and the entire Slick Slider community for creating the original package.
This fork was started by Jason Webb, Developer Advocate at Accessible360.
