dequelabs
Contrast Error “Background Color Cannot Be Determined” on Textarea
Product
axe-core
Product Version
No response
Latest Version
- [x] I have tested the issue with the latest version of the product
Issue Description
Expectation
The accessibility scanner should correctly detect the background color of the
Actual
The tool reports a false positive error:
“Element's background color could not be determined because it's partially obscured by another element.”
This happens even though:
There are no overlapping elements in the layout.
The issue occurs even when testing a standalone
Manual WCAG contrast testing shows the textarea meets the required contrast ratio.
How to Reproduce
Use the following minimal code snippet:
Run any automated accessibility scanner (e.g., Axe, WAVE, Chrome Lighthouse). The tool incorrectly flags the textarea with the error: “Background color could not be determined because it's partially obscured.”
Additional Context
This appears to be a known false positive in certain WCAG scanning tools when analyzing form controls, especially
Multiple tests confirmed consistent false positives regardless of styling.
Manual inspection validates that the component passes WCAG contrast requirements, so this may be a scanner limitation rather than an actual issue.
@Karthikeyan-mallow Thank you reporting this. This is what axe-core calls a "needs review" result. This is not an accessibility issue, rather it is axe informing you that it wasn't able to test an element, and that it will require manual review. We do this because we don't want people to overlook accessibility issues, assuming axe tested a thing that it did not test. A false positive occurs when something is failed when it shouldn't have been, which this is not.
Nevertheless I would like to look into this. We are always looking for ways to refine and improve these rules, and I appreciate that if you see a lot of these it can get frustrating. This is also why axe Extension has further tools to resolve these color contrast needs reviews, as well as the option to hide all needs review results.
If you can share the page on which you encountered this issue we can investigate the cause and look to see if there is a way we can avoid it.
@WilcoFiers I tested this scenario using a completely minimal page that contains only a single
There are no additional DOM elements near the textarea, and nothing overlaps it visually or structurally.
I see. Alright well definitely that message is confusing here. We can look into that.
Doing a little digging, the problem seems to be in our fullyEncompasses function in background color which checks to make sure that the parent element of the text fully encompasses the child text content. This check specifically looks at the overflow value of the element and adds the scrollWidth and scrollHeight to the left and top values of the parent node to gives us a right and bottom value. This makes the final check fail when comparing the position of the text to the parent as we don't include padding in our calculation (the textarea includes padding by default).
