Have commons consider presentational children

[WilcoFiers]

WAI-ARIA has a section on presentational children:

https://www.w3.org/TR/wai-aria-1.1/#childrenArePresentational The DOM descendants are presentational. User agents SHOULD NOT expose descendants of this element through the platform accessibility API. If user agents do not hide the descendant nodes, some information may be read twice.

Basically, if you do this:

<div role="img">
  <button>Hello</button>
</div>

What you get in the accessibility tree is just an img. That button does not exist. Because it is still focusable, there is now an element in focus navigation without a corresponding node in the accessibility tree. That explains the root cause of #601, and expands it a little, because it isn't exactly nested elements, it's focusable content inside of elements with "Presentational children: true" in ARIA. That "nested interactive elements" rule is actually very similar to the aria-hidden-focusable rule, except that the reason the focusable element is removed is a different one.

Axe-core does not take this into account anywhere; and there are quite a few places where it probably should. Ones that come to mind are:

• accessibleText()
• getRole()
• isVisible()

Since we've never had anyone report on this, I imagine this doesn't happen much in practice (I sure hope not). But it's probably worth considering anyway, and maybe to do some testing with different AT to figure out how consistent this behaviour is.

[Malvoz]

I imagine this doesn't happen much in practice (I sure hope not)

https://github.com/w3c/html-aam/issues/292 describes one such case.

[straker]

@WilcoFiers this now gets flagged by the nested-interactive rule as a violation due to the img element having focusable children. Is there anything else we should do for this issue?

[WilcoFiers]

My thinking on this has changed, now that I've learned browsers are inconsistent about this particular piece in ARIA. Some browsers will put them in presentation and others will not. Since axe-core can only test one of those scenarios, I think the one that will get us the best results is to not apply the presentational children logic. Take the img > button example from above. We'll probably want to flag an issue if either one of those two elements doesn't have a name. So I think keeping it "as is" is probably best.

That said - that seems like a good default. It might be nice to make this optional. If you're just interested in Safari, applying presentational children is the right thing to do. I think we should keep it open. I have for a long time wanted us to have a more configurable engine.