dequelabs / dequelabs/axe-core

Have commons consider presentational children

Open
#2,213 3 comments 1 reaction 0 assignees View on GitHub
commons feat rules
Dominant language
JavaScript
Stars
7.5k
Forks
933
Avg merge
2d 23h
Merged PRs (30d)
17

Description

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:
```html


Hello

```

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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.