Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support range widgets in toHaveDisplayValue #441

Open
Lukas-Kullmann opened this issue Mar 3, 2022 · 5 comments
Open

Support range widgets in toHaveDisplayValue #441

Lukas-Kullmann opened this issue Mar 3, 2022 · 5 comments
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@Lukas-Kullmann
Copy link

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.

@gnapse gnapse self-assigned this Mar 4, 2022
@gnapse gnapse added enhancement New feature or request good first issue Good for newcomers labels Mar 4, 2022
@idanen
Copy link
Contributor

idanen commented Oct 2, 2022

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
Copy link

Twipped commented Mar 22, 2024

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
Copy link
Member

gnapse commented Mar 22, 2024

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

@Twipped
Copy link

Twipped commented Mar 25, 2024

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
Copy link
Member

gnapse commented Mar 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants