Review item for contrast of inline element only occurs in some browsers

[marcysutton]

This was originally filed as part of the QA pass for our Firefox extension, but it's a problem in axe-core. A review item for an inline link that spans two lines is sometimes found for the ABCD Computech site: http://abcdcomputech.dequecloud.com/

In a handful of browsers, there is a contrast review item for this node:

<a href="contact.php">this page</a>

It falls through to the generic "Unable to determine contrast ratio" message. I think it's a problem with the code checking overlap, for which I've seen issues on inline elements. The link in this case wraps to two lines, sounding eerily similar to #556.

Browser Results

• aXe Chrome on Mac: review item found
• aXe Firefox on Mac: review item found
• aXe Chrome on Windows: review item found
• aXe Firefox on Windows: review item NOT found

Firefox on Windows is the only one that gets this right (there should be no individual review item). The surrounding body copy is a color violation (4.48:1), but the link itself is fine (9.40:1).

[marcysutton]

I've narrowed this to document.elementsFromPoint, with which only Firefox on Windows includes the link spanning a line break. It's so odd that there's a difference cross-platform.

I thought this was due to browser/platform differences, but the element stack code behaves the same in all browsers when I really dig in. The result difference with the incomplete is more likely caused by the page zoom level or viewport (where the text link no longer wraps at that font size).

document.elementsFromPoint consistently skips an inline element if it spans two lines: https://codepen.io/marcysutton/pen/NwRqqJ

To plug it in to our color contrast algorithm: I'm not sure how expensive this will be, but we could compare the element's client rects with the first parent element that contributes a background color. The only problem is we currently build up the element stack before we check colors. I want to rewrite that code to walk the DOM instead of checking for known pairings like input/label, and instead check for relevant backgrounds as we walk. Now that we know elementsFromPoint misses so many use cases, it no longer makes sense to do a preliminary shim step simply to gather backgrounds...might as well filter them as we go instead, since the current code has many gaps.