Support for inert coming to Chromium soon

[WilcoFiers]

See https://developer.chrome.com/blog/inert/

I haven't thought through all the implications of this but I imagine there are going to be some definition that need to be updated.

[Jym77]

https://html.spec.whatwg.org/multipage/interaction.html#the-inert-attribute https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/inert#browser_compatibility

[Jym77]

Seems to have three effects on us:

• inert elements are not focusable (affects 55 rules…)
• inert elements are not included in the accessibility tree (51 rules, many in common).
• inert element should very likely be considered as Programmatically hidden (50 rules, many in common).

inert may be overwritten by inert="false" on a descendant. So it acts more like an inherited CSS property (vs hidden which cannot be overwritten). Except we cannot use CSS language to describe all that, so it will be a bit annoying. This may end up with text like in Text inheriting its programmatic language from an element, so in turn we may want to share the definition of "value of the attribute on the closest inclusive ancestor defining it" 🤔

[Jym77]

Side question is whether we want to handle the fact that elements out of a dialog should be inert even without the inert attribute... https://html.spec.whatwg.org/multipage/interaction.html#modal-dialogs-and-inert-subtrees

This could notably impact focus traps in "aria-hidden element is not focusable"

[Jym77]

Decision:

• add inert example to each rule that use one of these 3 definitions (similar coverage as for aria-hidden).
• add dialog example to rules where it make sense.

[Jym77]

It seems that the AMM is going to map inert to aria-hidden="true". So we can have a note in "Programmatically hidden", similar to the one about hidden being the same as display: none.