James Craig

I've merged in the partial revert, and plan to re-revert that sometime next month. - https://github.com/web-platform-tests/interop-accessibility/issues/170

> a non-hidden control with a user-perceivable value (e.g., text input value or chosen option from a select, but not checkbox or radio button value) seems more like what we...

Yes, anytime an element is not rendered or interactive to mainstream users, I'd support it being removed from (or marked as hidden in) the accessibility tree. I agree that's likely...

From https://w3c.github.io/aria/#aria-busy > If it is necessary to make multiple additions, modifications, or removals within a container element that is already either partially or fully rendered, authors **_MAY_** set aria-busy...

> @cookiecrook, would this be a good candidate for WPT? I would not think so, because 1) aria-level is not yet testable in WPT, and 2) these are normative **_author_**...

> I don’t have a concrete example in mind, but could the opposite be possible? That is, while dynamically updating the DOM, there might be a state where aria-busy is...

> I am indeed seeing ariaRelevant in the accessibility WebIDL definition files for the 3 major browsers Yes, since this reflects the current reality, let's approve it.... In the meeting...

I haven't seen this pattern attempted before... @scottaohara @accdc @MelSumner do you agree? In any case, writing a test to make sure all engines do the same thing seems reasonable...

We'll also make sure the specs (AccName and/or HTML-AAM) explicitly acknowledge this expectation...

mentioned in the ARIA WG meeting to get some more thoughts on this.