Is thumbnail navigation fundamentally incompatible with accessibility?

[DicksB]

We've been using Slick 1.8 (with the Slick module For Drupal) for what I believe is a pretty common "photo gallery" use case, where one large slider is synced with a thumbnail carousel, and a user may navigate directly to a slide on the main slider by clicking a thumbnail. This functionality appears to be deliberately removed in Accessible Slick, according to:

#11

...and the synchronization example on the documentation page does indeed reflect that thumbnail navigation no longer works. The author of the Slick module for Drupal discovered this while testing a patch I worked on to add support for the Accessible Slick library to the module. There's some discussion of the deprecation in an issue here:

https://www.drupal.org/project/slick/issues/3220308

I'm hoping to confirm whether or not this is a deliberate change, or an unintended side effect of the deprecation. Do you think there's a way to restore this functionality while maintaining accessibility, or is this type of navigation just fundamentally incompatible with accessibility?

[jasonwebb]

Hey @DicksB!

Using one carousel with thumbnails to control another carousel with a single large image is absolutely possible with accessible-slick, and can be done in a few different ways depending on the UX you want to achieve! It sounds like how you're thinking about thumbnail navigation is different than how I had thought of it, so the demos provided may not line up with your expectations even though we're using the same words.

One thing that may be causing some confusion here is that the docpage for this repo (like the docpage for the original package) really only shows very basic technical demos of individual low-level features and options, which may or may not reflect realistic use cases on their own. For example, the Slider Syncing demo shows how the asNavFor option works, but that may or may not be what you want for a full-on photo gallery widget.

Since the focusOnSelect option was deprecated, the larger slider does not update when a different thumbnail slide is clicked now. But that's a good thing because these thumbnails were not marked up using semantic <button> tags in the original demo, so they were totally inoperable for keyboard and screen reader users. So in this case, the deprecation of the focusOnSelect option is forcing us to implement more accessible markup or forgo the click interaction. I didn't want to overcomplicate the code snippet, which is really focused on the asNavFor option after all, so I chose to skip the click interaction. I can see how that could cause some confusion!

Check out this realistic code sample for a PDP image gallery carousel, found in the CodePen collection linked in the main README for this repo. This is a more complete example that uses multiple features, which is why it isn't directly embedded in the docpage (though may I should link to it? 🤔). In that sample, the thumbnails are marked up using semantic <button> tags, and are therefore operable by all users. Since this use case clearly indicates the "active" thumbnail visually for sighted users, this state also needs to be conveyed to screen reader users too somehow (per WCAG 1.3.1, or maybe WCAG 4.1.2). Since this isn't something is done in a generalized way by accessible-slick (or the original Slick package), the attribute aria-current="true" is dynamically added to the active thumbnail button.

If what you want is for the larger carousel to change whenever a user activates a thumbnail button AND when they activate the previous or next buttons, then you might be able to mash up that CodePen with the asNavFor demo. But you'd still need to make some manual adjustments when the prev/next buttons are activated, like moving aria-current="true" to the appropriate thumbnail button. Note that this isn't needed in the Slider Syncing demo because "center mode" is used, which automatically appends the text " (centered)" to the wrapper of the active thumbnail slide. Personally, I would recommend not using asNavFor in this use case, and instead using the API events and methods to create the specific syncing and interaction behavior you're after, since you'll already have to use the API to make ARIA adjustments anyway. I'd be happy to provide a code sample showing how this could be done, if that would help!

Regardless of whether you want the larger carousel to change automatically or only when a thumbnail button is activated (or both), forcefully moving a user's keyboard focus (and thus their "context") in general is pretty disruptive and unexpected, and sometimes a violation of WCAG 3.2.2. That's why the focusOnChange and option was deprecated, which you can read more about in issue #11. So yes, I can confirm that the deprecation of these two options is very much intentional!

[DicksB]

I appreciate the quick response! So it sounds like we may need to achieve this in the markup generated by the module. I'll pass that along to the author (if he hasn't seen this already) and investigate the possibility. Thanks!