Jean-Yves Moyen

Another case I've found today, somewhat related to the button example: ```html Foo ``` `Name#fromDescendants` does not filter out `aria-hidden` descendants (or `hidden` descendants). Of course, we need to already...

Which, I'm afraid, makes this a bug 🙈

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

Seems to have three effects on us: * `inert` elements are not [focusable](https://act-rules.github.io/glossary/#focusable) (affects 55 rules…) * `inert` elements are not [included in the accessibility tree](https://act-rules.github.io/glossary/#included-in-the-accessibility-tree) (51 rules, many in...

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...

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.

It seems that [the AMM is going to map `inert` to `aria-hidden="true"`](https://github.com/w3c/html-aam/pull/410). So we can have a note in "Programmatically hidden", similar to the one about `hidden` being the same...

Maybe `display: grid` can also handle stuff.

It is only the **required** properties that need a valid element for this rule. In your example, `aria-errormessage` is not required by `textbox` therefore the rule passes (this is essentially...

Update this + "required properties" rule to say that `aria-control` is not really required, based on [authoring practice](https://w3c.github.io/aria-practices/#wai-aria-roles-states-and-properties-6) (second bullet) + open an issue with ARIA.