Color contrast: text that overflows its parent should go into incomplete

[marcysutton]

In working on #610, we found another use case that isn't quite covered: if a block element with text is positioned over an element with a background color but the text overflows, the current color algorithm causes a false positive for the overflowed text. It should return null instead of returning the background color, since we can't really tell. We talked about doing some overflow testing of the text node.

Here's a test that fails both in develop and in the color fixes PR. I didn't want to let it hold up the work that's been ongoing for a while:

it('should return null for a multiline block element not fully covering the background', function () {
	fixture.innerHTML = '<div style="position:relative;">' +
		'<div id="background" style="background-color:rgba(0,0,0,1); position:absolute; height:20px;"></div>' +
		'<p style="position: relative;z-index:1;" id="target">Text content Text content Text content Text content Text content Text content</p>' +
	'</div>';
	var actual = axe.commons.color.getBackgroundColor(document.getElementById('target'), []);
	assert.isNull(actual);
	assert.equal(axe.commons.color.incompleteData.get('bgColor'), 'elmPartiallyObscured');
});

The passing version in #610 works when the target has a defined width so the line breaks, and it goes through the new logic for multiple clientRects. But this one doesn't have multiple rects, so we have to look at the text node itself.

[marcysutton]

When I looked into fixing this (but decided to wait), the most relevant section of code was the contentOverlapping function in get-background-color.js which only looks at the top left corner.

Perhaps we should sample the element stack from more than one corner, and put it into incomplete if the arrays don't match. We have to weigh this with performance, of course...but it's a similar problem to the inline element checking I had to do. One thing that makes this quite difficult is that different browsers have different results with getClientRects(). Firefox returns a single rect, while Chrome/Safari return multiple. That's primarily why I declined to move forward with fixing it now.

[WilcoFiers]

Not sure how or when, but this seems to be fixed.