Slick: Aria attributes visible for slide even after setting accessibility to false

[sunnydav]

Hi,
This is an amazing carousel and we are actively using it. However, I have discovered that the aria-hidden attributes are set for the slides even if the accessibility flag is set to false. I think this is incorrect.
We have a requirement from ADA perspective to allow only tabbing through each slide without tabbing on the arrow buttons. I can set the tabindex for these buttons programmatically to -1 and prevent the tabbing but since the aria-hidden is defaulted to true when carousel is initialized, the invisible slides are never read even though the user can tab through them and are visible now.
Why not set the aria tags only on basis of the accessibility flag to allow the flexibility of setting them based on user requirement?

[qbunt]

Same issue as https://github.com/kenwheeler/slick/issues/1544. May be faster to fix and PR on your own.

[ahmadalfy]

The accessibility option only control tabbing and arrow key navigation. Perhapse we need another option to enable/disable aria attributes?

[qbunt]

@ahmadalfy You may not classify it as a bug, but it's certainly preventing easy use of this library for people with screen readers, which I would definitely classify as a bug.

As @sunnydav mentions above, adding ARIA attributes of any kind are going to influence ARIA based screen readers across the board. It seems redundant to have a second setting that would turn these attributes on/off when really ARIA attributes should only be added/removed when this option is set to 'true'.

This is a real problem when you need to override the ARIA attributes because Slick doesn't implement what you need, there's no real way to de-activate them completely. Not all accessibility requirements are asking for the same thing.

This would be my vote:
accessibility:false; -> no ARIA tags on anything
accessibility:true; -> ARIA tags where needed, using 'aria-hidden' very carefully

[qbunt]

It may actually be smarter to remove this implementation completely rather than leave it the way it is.

[ahmadalfy]

@qbunt can you please explain what is wrong with the current implementation and I will see what we can do to fix it?

[qbunt]

The aria-hidden=true attribute on elements (even when set to accessibility:false will be evaluated with screen reader software in a way that's not desirable. Because that property appears with the accessibility config true or false, if _you need to change_ this, you have to loop through every slide and remove the aria-hidden attribute manually on every change. It makes supporting WCAG standards (the ADA compliance @sunnydav mentions) really challenging.

If you set accessibility:false there should be _no ARIA tags on any element_ by default. The aria-hiddenproperty is explained here pretty well.

If you are attempting to use Slick in an environment where you have to support WCAG standards (banking, e-commerce, retail, etc), Slick makes this nearly impossible with the current implementation, as the ARIA attributes are not compliant. WCAG 2.0 standards for carousels are well established.

My point is, either remove all the ARIA attributes if accessibility:false _or_ remove the entire implementation, as it makes supporting the published standards far more work than it should be.

This issue may be a dupe, as I filed an issue here https://github.com/kenwheeler/slick/issues/1544.

[cshold]

I agree, the aria implementation could use some work. I've opened a new issue about aria-live="polite" here for those interested.

[ahmadalfy]

@cshold :+1:

[qbunt]

Hey @ahmadalfy, any update on this, I know this is likely not high on the priority list, but it'd be great to hear if it's going to get some love or if a PR is needed to close this out. Cheers.

[JoshuaKGoldberg]

This is still an issue, and is still relevant. An opt-out mode for aria-hidden is, ironically, really useful for making usage of this library accessible.

[karlchelton]

An opt out feature needs to be added.. for the sake of accessibility and audit reviews.

[fisher2470]

Also currently experiencing this issue, an opt-out is needed

[JohnMDDD]

I also am in need of a solution to this problem with ADA compliance. An opt-out is needed!