Ability to query a video and still respect the accessibility tree

[danny-does-stuff]

Describe the feature you'd like:

It is not possible to query for a video using the *ByRole queries, but these are the only queries which respect the accessibility tree. This means that if you have a video element that is supposed to be hidden, you cannot test it in the same way that you would test other hidden elements. Allowing other queries to opt-in to respecting the accessibility tree was discussed in #929, but this specific case of finding a video was not brought up.

Suggested implementation:

render(<div aria-hidden={true}>
   <video src="abc" aria-label="The Video" />
</div>)

expect(screen.queryByLabelText("The Video", { hidden: false } )).toBe(null)

Describe alternatives you've considered:

The current workaround would have to be something like this, where the developer would need to find the nearest parent that is hidden, which makes the tests too familiar with the layout of the html IMHO

render(<div aria-hidden={true}>
   <video src="abc" aria-label="The Video" />
</div>)

const video = screen.queryByLabelText("The Video")

expect(video.parentElement).toHaveAttribute('aria-hidden', 'true')

Teachability, Documentation, Adoption, Migration Strategy:

This would only require adding the new option hidden to all queries besides *ByRole. The option would default to true.

[eps1lon]

Thanks for the detailed description.

Could you expand on how assistive technology like screen readers discover these elements? Is there any specification for <video /> with regard to the a11y tree?

[danny-does-stuff]

I am not familiar with how screen readers discover video elements, and honestly, I wouldn't know how to figure that out either. I'm quite a novice with these things. What I do know is that in the Chrome Dev Tools, in the Accessibility section, the video is marked as "role: Video", although I can see here that neither 'video' nor 'Video' are valid aria roles.

[dalevfenton]

I'm interested in an answer to this question as well, as @danny-does-stuff mentioned the chrome dev tools do display a video element in the accessibility tree so it feels like it should be discoverable that way when testing (especially since byRole is the preferred way to assert elements)

it looks like there is discussion of adding video and audio roles to the spec here: w3c/aria#517 and as it's not official I suppose there really isn't anything to do in dom-testing-library until the spec supports it

would it be worth adding some documentation around a best practice for testing these elements in the mean-time?

[MatanBobi]

Thanks for the offer @dalevfenton.
IIUC, the video and audio elements can only have application role. It doesn't look like the spec currently has dedicated roles for these elements (e.g. video or audio roles). If you have a best practice you'd like to share, I think an explanation in this issue will be a great place :)