Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
color-contrast incorrectly calculating background color of an element in closed `<details>`
See original GitHub issueProduct: 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>
Issue Analytics
- State:
- Created a year ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Text elements must have sufficient color contrast against the ...
The Color Contrast rule uses a snapshot of the screen to extract the background and text color of the view. Upon finding colors,...
Read more >background color detected by color contrast is incorrect in table
I have a large background image + dark background color that is showing the insufficient color contrast of 1.00 when I pin the...
Read more >Color and contrast accessibility - web.dev
The contrast is calculated based on the following features: Spatial properties (font weight and text size); Text color (perceived lightness ...
Read more >Understanding Web Accessibility Color Contrast Guidelines ...
The contrast ratio explains the difference between the lightest color brightness and the darkest color brightness in a given range. It's the ...
Read more >The Myths of Color Contrast Accessibility - UX Movement
The reason the contrast ratios failed with the white text is that it has high luminance and is on a background with high...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.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 theopenattribute when expanded, so we should be able to use that to determine visibility.