axe-core icon indicating copy to clipboard operation
axe-core copied to clipboard

False positive color contrast violation of elements inside particular tables

Open RyanBerliner opened this issue 10 months ago • 1 comments

Product

axe-core

Product Version

4.10.2

Latest Version

  • [x] I have tested the issue with the latest version of the product

Issue Description

Expectation

I would not expect the <span>Lorem</span> to be reported as a color contrast violation.

Actual

The <span>Lorem</span> is reported as a color contrast violation.

How to Reproduce

I'll preface by saying that this is a very bizarre bug observing just it's symptoms... It took quite a bit of time to reduce it down to what I think is the base case. I've added some notes in the snippet below that elaborate a bit more on what role each part plays. I've also added a screenshot that shows the output from the code below.

An image of the  Lorem span clearly displayed as white text on a black background
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Contrast Violation Test</title>
  </head>
  <body>
    <table cellspacing="0">
      <tbody>
        <tr>
          <td style="background: #000; color: #fff;" rowspan="2">
            <span>Lorem</span>
          </td>
        </tr>
        <tr style="background: #fdfdfd;"></tr>
      </tbody>
    </table>
    <!--

    Some changes that when made independently of each other will make the
    violation go away.

    A) Remove the cellspacing attribute
    B) Update cellspacing attribute to value > 1
    C) Remove the rowspan attribute
    D) Update the rowspan attribute to 1
    E) Add 1 or more td's to the first tr (order does not matter)
    F) Remove the second tr's styling 
    G) Update the second tr's styling to (at least) one shade whiter, either
       #fefefe or #ffffff. #fdfdfd seems to be a threshold.
    H) Remove the second tr
    I) Remove the wrapping span on "Lorem"

    There are certainly more changes you could make, but I believe this is the
    base set. Change G also stands out to me as perhaps the strongest clue
    because of how strange it is. It's worthwhile to also mention that
    cellspacing is technically a deprecated attribute and is not valid html5.

    -->
  </body>
</html>

RyanBerliner avatar Feb 07 '25 00:02 RyanBerliner

Thanks for the issue, I'm able to reproduce the bug with the provided code.

Note to self: this ones a bit tricky and I'm not sure what the best way to solve it is. Looking at the element stack shows that the 2nd tr (the one with styling) is above the 1st td in the stack ([span, tr[style], td, tbody]) [the 1st tr has a height of 0 which is why it's not in the stack], and that causes the background to get reported as #fdfdfd. The element debugger of the nodes also shows that the 2nd row overlaps the 1st . So I don't necessarily think that the stacking code is incorrect.

My inclination is that this has more to do with how browsers lay out tables and rowspan than our stacking code being incorrect. If I add a column to the 2nd row, it gets placed after the column of the first row. I'm not sure how best to handle this in the code.

Image

straker avatar Feb 07 '25 15:02 straker