I think usually with tentative tests, we expect there to be a standards document, and the test is tentative because the pass condition presumes one outcome of an ongoing technical discussion.
Allowing a class of tests that depend on something that's entirely nonstandard — moreso even than single-vendor WICG proposals — does seem like a step change compared to what's accepted today.
I agree with the underlying (initial) goal of making the accessibility tree available to automation. But I don't see how it benefits us to start with tests that depend on the current Chromium behaviour, rather than starting with some agreement over the general shape the API should take (and FWIW I strongly suspect that standardising "an API that returns the current a11y tree" is not the hard part here; it's making a11y trees from different implementations similar enough — or even standard — so that you can write meaningful tests covering multiple browsers).
I think usually with
tentativetests, we expect there to be a standards document, and the test istentativebecause the pass condition presumes one outcome of an ongoing technical discussion.Allowing a class of tests that depend on something that's entirely nonstandard — moreso even than single-vendor WICG proposals — does seem like a step change compared to what's accepted today.
I agree with the underlying (initial) goal of making the accessibility tree available to automation. But I don't see how it benefits us to start with tests that depend on the current Chromium behaviour, rather than starting with some agreement over the general shape the API should take (and FWIW I strongly suspect that standardising "an API that returns the current a11y tree" is not the hard part here; it's making a11y trees from different implementations similar enough — or even standard — so that you can write meaningful tests covering multiple browsers).