feat(material/slider): Update range slider to use `role="list"` around the slider thumbs

[jelbourn]

Currently the range slider presents itself as two independent slider controls. If we were to make the mat-slider element role="list" and wrap each <input> element in a role="listitem", assistive technology will announce indices for the sliders as well as the label for the entire range slider as well. The rendered result would look something like

<mat-slider role="list" aria-label="...">
  <div role="listitem"><input type="range" aria-label="..."></div>
  <div role="listitem"><input type="range" aria-label="..."></div>
  <div class="mdc-slider__track" aria-hidden="true">...</div>
  <mat-slider-visual-thumb aria-hidden="true">...</mat-slider-visual-thumb>
  <mat-slider-visual-thumb aria-hidden="true">...</mat-slider-visual-thumb>
</mat-slider>

The non-listitem children of role="list" need to be given aria-hidden to prevent them as counting as list items.

The work here would be

• [ ] Create a proof of concept
• [ ] Test the proof of concept in all screen-readers that we support
  • [ ] ChromeVox
  • [ ] NVDA
  • [ ] JAWS
  • [ ] VoiceOver
  • [ ] TalkBalk
• [ ] Make the change
• [ ] Update documentation for best practices

[noobyogi0010]

Hi @jelbourn ! I would like to work on this issue. Can I take it up if no one is working on it?

[jelbourn]

@noobyogi0010 this is open for contribution if you want to put together a proof-of-concept PR. Do you have access to the various screen-readers mentioned in the original issue for verification?

[wagnermaciel]

@jelbourn This seems really trivial to implement, but I don't have any screen readers set up. Would it make sense for me to implement this and get Zach to test & review the PR?

[jelbourn]

@wagnermaciel yeah, this would be a good collaboration for you and @zarend to work together and prototype / test this approach. If we find that the approach works well, we can raise it to the Material Web team and see if they want to use it too, or if we should just do it ourselves.

[zarend]

kksg, @wagnermaciel we can talk more offline in January

[zarend]

Hi @jelbourn,

We looked into list/listitem, and here's what we initially came up with. In theory, it might make sense to wrap the two sliders in a list. That way it's semantically communicated that the two are connected.

assistive technology will announce indices for the sliders as well as the label for the entire range slider as well

We definitely want to confirm that AT reads an appropriate label for both the start and end slider. "announce indices" – I don't want to go as far as dictating behavior to the AT because that can cause unintended consequences. Wrapping patterns in another pattern works well for patterns that truly are compound, such as list or menu. AFAIK slider role is not specified as being part of a parent or any kind of compound widget.

App developers could always add role="group" to the <mat-slider/> if they are of that opinion that it works better for their application. Group is less specific than list.

I definitely recommend we implement aria-valuemin and aria-valuemax as recommended by the ARIA Author Practices Guide Slider (Multi-Thumb) pattern. That way the assistive technology would get the information it needs from the start thumb when focused on the end-thumb and visa versa.

Implementing aria-valuemin and aria-valuemax seems like a definitely improvement to me. Would you like us to continue to look into using the list/listitem pattern?

-Zach

[jelbourn]

I think that wrapping the thumbs in a list is a nice-to-have improvement, but not super high priority until we've dealt with bugs/problems on other components (including tree)

[zarend]

Sg, I looked at our range slider, and we're already following the recommendations from ARIA Author Practices Guide Slider (Multi-Thumb) pattern 👍