1.0.1 • Published 3 years ago

@accessible360/accessible-slick v1.0.1

Weekly downloads
26
License
MIT
Repository
github
Last release
3 years ago

accessible-slick

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!

Demo

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!

CDN

Example using jsDelivr

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>

Package Managers

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 <link> and <script> tags without having to even touch your existing JavaScript code!

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:

New features ✨

Feature changes ⚠️

Usage

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:

New settings ✨

In addition the original functionality, the following new settings have been added:

SettingTypeDefaultDescription
arrowsPlacementstring ('beforeSlides' | 'afterSlides' | 'split')nullDetermines 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.
instructionsTextstringnullInstructions 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!
pauseIconstring (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.
playIconstring (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.
regionLabelstring'carousel'Text to use for the aria-label that is placed on the wrapper.
useGroupRolebooleantrueControls whether role="group" and an aria-label are applied to each slide.
useAutoplayToggleButtonbooleantrueControls 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!

Deprecated settings ❌

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.

SettingReason(s)
accessibilityEqual 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.
focusOnChangePer 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.
focusOnSelectUnnecessary 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.

Development

If you'd like to contribute changes or just make modifications for your own use, use the following process:

  1. Install all the dev dependencies with NPM:
npm install
  1. Make your changes to the source files. You'll want to focus on:

    • slick/slick.js
    • slick/slick.scss
    • slick/slick-theme.scss
  2. 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
  1. Check your changes by loading up docs/index.html in your browser.

Contributing

See the contributing guidelines.

Credits

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.