Are /accessibility/crashtests tests valuable for Interop 2024?

[foolip]

While reviewing some of the accessibility-related proposals for Interop 2024, the Interop Team has looked at which existing tests in WPT might be appropriate to include from the ones already labeled accessibility:

https://wpt.fyi/results/?label=master&label=experimental&aligned&q=label%3Aaccessibility

There are 50 crashtests here that we're not sure about:

https://wpt.fyi/results/accessibility/crashtests?label=experimental&label=master&aligned

The only failure there is due to web-platform-tests/wpt#13183 (comment). Given that there aren't any actionable failures here, is it worthwhile to include them?

@cookiecrook can you advise?

[cookiecrook]

There's one new test (with timeout failures across the board) since the time you filed this issue, but I don't have a strong argument for or against keeping the crashtests dir in Interop 2024. @aleventhal wrote the majority of those and may have an opinion.

[aleventhal]

The test you linked with the tinmouts doesn't seem to be one of the B accessibility crash tests (although it's pretty weird that it's timing out across all browsers). As far as the tests I wrote, I think they have a lot of value if you're trying to implement aria-owns to restructure the a11y tree. There are some weird cases such as tree cycles that you need to be careful about. I'm not sure where Apple is on implementing aria-owns that way, but I think it would be highly valuable for other browsers to have these in your tests. That said, it doesn't bother me if others don't see the value and don't want to use them.

…

On Sat, Feb 3, 2024 at 2:45 AM James Craig ***@***.***> wrote: There's one new test <https://wpt.fyi/results/accessibility/crashtests/svg-mouse-listener.html?label=master&label=experimental&aligned&q=label%3Aaccessibility> (with timeout failures across the board) since the time you filed this issue, but I don't have a strong argument for keeping them in Interop 2024. @aleventhal <https://github.com/aleventhal> wrote the majority of those crashtests and may have an opinion. — Reply to this email directly, view it on GitHub <#100 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZWDIVN7DIYZ6DTN5NLYRXTIRAVCNFSM6AAAAABCBVGXH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGIYDCNBUGM> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[jgraham]

The test you linked with the tinmouts doesn't seem to be one of the B accessibility crash tests (although it's pretty weird that it's timing out across all browsers).

It's timing out because currently crashtests don't support testdriver (see web-platform-tests/wpt#13183 which is mostly about reftests; crashtests are probably slightly easier, but the story is similar).

For now you'd need to rewrite that as a testharness test.

[cookiecrook]

@jgraham @boazsender I've tracked that change in #106. Thanks.

@foolip Seems like the interop-2024-accessibility label has been removed from the crashtests dir, so can this issue be closed? If so, please do. Thanks!

[cookiecrook]

Confirmed removal of the crashtests. Closing.

[aleventhal]

I didn't see a reason posited for their removal. They aren't useful? I assume these are useful if anyone is implementing aria-owns.

[chrishtr]

I didn't see a reason posited for their removal. They aren't useful? I assume these are useful if anyone is implementing aria-owns.

Just to clarify, this is about removing them from Interop 2024, not deleting the tests.