Support `range` widgets in `toHaveDisplayValue`

[Lukas-Kullmann]

Describe the feature you'd like:

As far as I understand it, the toHaveDisplayValue matcher takes some kind of input element and computes the value that the user can see. However, it does not work properly for range widgets (e.g. <input type="range">, but also elements with role="range" or role="slider").

According to the standard, the aria-valuetext attribute should be rendered when provided. If not, aria-valuenow should be used (which is implicitly set for <input type="range"> elements to their value).

I think it would be a good addition to support range widgets with the toHaveDisplayValue matcher.

Suggested implementation:

We need some way to calculate the element's value text if it is a range widget. I'm not sure if this should be done here or in the dom-accessibility-api. But probaply there.

Then we just need to extend the matcher to also accept range widgets and use the value text for comparison.

Describe alternatives you've considered:

I'm actually not sure if the toHaveDisplayValue matcher would be the best fit. Maybe an additional matcher would make sense. Something like toHaveValueText. That would be confusing to me personally however since I would not be very sure which one to use when. I think this is already a problem with the difference between toHaveDisplayValue and toHaveValue.

Teachability, Documentation, Adoption, Migration Strategy:

I don't really know what to write here, but I think that range widgets are not that uncommon and it would be cool to be able to test the value of them in the same way we can test things like selects.

[idanen]

I missed this one when opened #478 . So, I thought .toHaveValue() should just work for aria-valuenow, so that's how I implemented #479 . Maybe they complement each other?

[Twipped]

I just landed here trying to figure out how to assert that an indeterminate progressbar is accessible. These should be the correct tags for it, but jest-dom doesn't seem to recognize any of them for toHaveDisplayValue, toHaveAccessibleDescription, or even toHaveTextContent

aria-busy="true"
aria-live="polite"
aria-valuemax="100"
aria-valuemin="0"
aria-valuetext="Loading..."
role="progressbar"

[gnapse]

This issue is about <input type="range">. Can you open an issue about progress bars?

[Twipped]

The issue appears, to me, to be about the behavior of toHaveDisplayValue in conjunction with aria-valuetext, which as the spec says on the linked page:

This property is used, for example, on a range widget such as a slider or progress bar.

Yes the issue title explicitly mentions range elements, but the point I'm making is that the bug is with the aria property not being handled correctly, regardless of the element being used. Perhaps this issue could be renamed?

[gnapse]

The toHaveDisplayValue custom matcher has the following purpose:

This allows you to check whether the given form element has the specified displayed value.

A progress bar, or a role="slider" element, are not form elements. Yes, they have the concept of what their current value is (the current percentage of the progress bar, or the value of a slider). But I'm very hesitant to extend toHaveDisplayValue to support these types of elements that are not related to a form. If that's what you're suggesting.