[Bug]: Slider has accessibility issue when label-visibility="none"

[Rocss]

Code of conduct

• I agree to follow this project's code of conduct.

Impacted component(s)

sp-slider

Expected behavior

No accessibility issues

Actual behavior

.to.be.accessible() fails when using sp-slider with label-visibility="none"
Same error we get in the tests can be observed in the storybook as well.

Screenshots

What browsers are you seeing the problem in?

No response

How can we reproduce this issue?

1. Go to https://opensource.adobe.com/spectrum-web-components/storybook/index.html?path=/story/slider--no-visible-labels
2. Click on "Accessibility" add-on tab
3. Observe

Sample code that illustrates the problem

No response

Logs taken while reproducing problem

No response

[Rocss]

@jnurthen / @nikkimk I think the fix here would be to make use of the aria-label instead of the aria-labelledby?

[nikkimk]

The problem is that more than one label element is using the for attribute for the input, the text and the value when en element can only have one label. Only the text itself is a label.

To fix this, we could model the slider after this slider pattern, where we can also leverage the aria-valuemax, aria-valuemin, and aria-valuenow.

@jnurthen what are your thoughts?

[jnurthen]

Its normal that this fails accessibility because WCAG 3.3.2 requires a visible label for form fields. You cannot meet accessibility requirements without one.
aria-label may resolve the audit (as it becomes difficult to automatically check the standard once you do this) but absolutely doesn't fix the underlying WCAG issue.

[Rocss]

@jnurthen / @nikkimk thank you for the comments!
In this case, I think it is actually expected to see a failure in the accessibility check when no visible label is provided.
I find it weird that Spectrum allows it though: https://spectrum.adobe.com/page/slider/#Review-label-less-designs

make sure to have the design reviewed and approved by an accessibility expert

Unfortunately this does not really happen

[jnurthen]

I'll also note that this is a best practice check in axe which means that it is not a certain fail.
The checker can only check the programatically associated labels and it has found these are not visible so it is raising the error. If there were a different visible "label" even if not programatically associated it would pass this SC.

If we think this story should pass then one could configure storybook to not run this test for this story.
See the Readme in the addon-a11y package within storybook for details of how to do this.