axe-core
axe-core copied to clipboard
dequelabs
color-contrast incorrectly calculating background color of an element in closed `<details>`
Product: axe-core
Expectation: When calculating contrast ratio for an element in closed <details>, either:
- take background color of open
<details>element (might not be possible without page interaction, which could be a roadblock), - or don't take any background color at all, effectively skipping the color-contrast test for this element.
- or if we really really would like to take background color of where the element would have been if the
<details>element was open, ignore<details>'s siblings when calculating background colors, because they will be pushed down when<details>is eventually opened.
Actual: background color is taken from the place where the element would have been if the <details> element was open. Unfortunately, in our example, in this place we have a dark blue button which, when combined with black text, fails the test.
Motivation: Current behavior is obviously faulty.
axe-core version: checked on: 4.0.0, …, 4.1.0, …, 4.2.0, …, 4.3.0, …, 4.4.0, …, 4.4.2
Browser and Assistive Technology versions
Chrome 103.0.5060.53
Repro:
<html lang="en-US">
<head>
<style>
span {
position: relative;
}
button {
background-color: darkblue;
color: #fff;
}
</style>
<title>color-contrast bug</title>
</head>
<body>
<header>
<h1>color-contrast bug</h1>
</header>
<main>
<details>
<summary>Summary</summary>
<span>Some text</span>
</details>
<button>A blue button</button>
</main>
</body>
</html>
It appears that the problem is in filteredRectStack function, which in this case, returns [span, button, main, body, html].
Looking at the issue, it appears we don't treat elements inside the <details> as hidden when the element is collapsed. As is, we think the <span> element is currently visible and positioned right above the button, so that's why we reporting the overlapping element.
I believe <details> elements have the open attribute when expanded, so we should be able to use that to determine visibility.
Need to discuss with Wilco the ramifications of saying elements inside closed detail elements are hidden as we may not run axe-core rules against them.
We discussed this and the resolution is we'll update the is-hidden function to account for this. This means rules will not run against elements inside of a closed <details> elements and users will need to expand the details in order to get accessibility checks.
Validated with the latest develop branch code base, and here for the test script, inside <details> closed tag color-contrast rule as it is counting the elements inside closed details as hidden
<main>
<details>
<summary>Summary</summary>
<span>Some text</span>
</details>
<button>A blue button</button>
</main>
