Can a screenreader read the content of a slide, or keyboard user focus inside it ?

[Semaho]

Hello !
I've landed here because of an a11y audit, the readme intro is spot on ;)

First, let's show you what the carousel looks like :

Please note that despite my experience in web dev, I'm a complete novice regarding screenreaders.

So I had a ticket opened because the content of the slides - that are not images as you can see - is not focusable on keyboard, thus keyboard user cannot access the link inside.
I see there is still the aria-hidden attribute on each slide, making the slide unreadable (I guess ?) by screenreaders.
I tried Narrator without success, but as I told you, I'm not the best user of it.

My question is : will screenreaders be able to read the content of those slides ?
If no, does it mean that this fork only makes accessible a "visual" carousel, like a photo slider ?

I don't know what would be the best behaviour for this, I know it's not the best component for a11y, but anyway that's what the business wants.

I'm opened to any suggestion, even if it means creating a new fork for that purpose !

Update :
It seems that only in centered mode, the active slide also have aria-hidden=true, is that on purpose ?
It makes it unfocusable for a keyboard user, right ?

[jasonwebb]

Hey @Semaho! If slides that are not visually hidden are getting the aria-hidden="true" attribute, that would definitely be a defect that we need to fix. Let's investigate!

My question is : will screenreaders be able to read the content of those slides ?

It makes it unfocusable for a keyboard user, right ?

When aria-hidden="true" is added to an element, that element and all of its child elements are hidden from screen readers. However, this does not affect whether or not any of those elements can receive keyboard focus, since not all keyboard users are screen reader users, and vice versa. To prevent keyboard focus from landing on interactive elements, we need to add tabindex="-1" to each of them. In accessible-slick whenever a slide is visually hidden, the wrapper element of that slide is given the aria-hidden="true" attribute and all of its interactive child elements are given tabindex="-1".

It seems that only in centered mode, the active slide also have aria-hidden=true, is that on purpose ?

Can you provide an isolated code sample (CodePen, CodeSandbox, etc) showing this in action? I am not able to replicate this behavior using the Center Mode example on the docpage. As I move between slides, it looks to me like the centered slide never gets aria-hidden="true". I wonder if there is something in your configuration options or some custom JS that is causing this 🤔 If you have a code sample showing this issue that would help troubleshoot what is going on.

[Semaho]

Hi @jasonwebb !
I started working on a fork until I realised it could be a defect, because in other cases the content of the slides is accessible indeed.

https://github.com/Semaho/accessible-content-slick

docs/demo.html contains a quick replicate of the use case, the issue is on mobile (<768px) when the carousel switches to centered mode.
Is it enough for you to test ? If no I'll make a CodePen so you can investigate.

You've probably seen it by now, but I also proposed the related PR : #32
Note that my fork fixes the issue, but you can easily switch back to your current implementation, it's a one-line change : https://github.com/Accessible360/accessible-slick/pull/32/files

Thank you !

[jasonwebb]

I took a look at the demo.html file in the master branch of that repo, and I'm not to replicate the behavior you're describing. When I set the viewport width to be under 768px, I see that the responsive options are activated, which enables center mode. Whether I refresh or just resize the page without refreshing, I do not see aria-hidden="true" added to the centered slide, except when I navigate to a different slide, which is expected (see attached screenshot below).

Can you provide a list of specific steps I can follow to replicate the issue(s) you're seeing?

[Semaho]

Did you replace Slick version by the current public version ?
I mentionned it quickly, but during my tests I fixed the issue on my fork. I guess switching to the CDN version should make the bug re-appear.

You can update my fork, I switched back to the current version. As you can see, all slides have aria-hidden=true :

[jasonwebb]

Sorry for the delay, this one was not easy to figure out! It looks like what is going on here is actually a bug in the core Slick Slider library that happens when using centerMode: true and infinite: false. There seems to be a logic bug that causes Slick Slider to think that the visible slides are not visible, so it never adds the .slick-active class to them. This happens when there is 1 slide visible, but it also happens when there are multiple slides visible - none of them get the .slick-active class, and therefore none of them get aria-hidden removed from them.

You can actually replicate this behavior yourself with the original Slick Slider library using the following CDN URL, and using the centerMode: true and infinite: false options on any slider.

https://cdnjs.cloudflare.com/ajax/libs/slick-carousel/1.8.1/slick.min.js

Since this appears to be a bug with the core Slick Slider library's logic around calculating which slides are visible when the centerMode: true and infinite: false options are used, I'm thinking this would need to be addressed in the original library's repo. When the bug is fixed there and a new version is published, that new version can be integrated here easily.

To be clear, the fact that aria-hidden="true" (and tabindex="-1" on inner focusable elements) doesn't get removed from slides that seem to be visible IS a problem, but the cause of that problem is actually found in the core library's source code and not in the accessibility enhancements that the accessible-slick source code provides. The behaviors you are describing above are really a symptom of the underlying issue, which needs to be addressed at the source.

Let me know if that makes sense to you, and if you have any other findings or questions to chat about!

[Semaho]

Thank you for the investigation !

As you probably know better than me, the original repo is not actively maintained anymore so I guess we'll go for a fork.

Thanks for your time 🙂