Contrast analyser doesn't factor in CSS shadow

[DavidMacDonald]

A client who met contrast minimums by creating a 360 degree shadow around text. aXe measured foreground text and background but did not factor in the shadow... this would be tricky programming to remedy. It would require ensuring the shadow surrounds the text and that the shadow is sufficient, but I think it's worth investigating further, because I've had to over ride the aXe report.

[marcysutton]

We should be able to check for a CSS text-shadow if it's directly on the element (and not a pseudo-element). But how much blur, spread, etc. makes the shadow readable? We'd have to compare those values along with shadow color to the text and background colors to see if there is enough of a difference.

[Volker-E]

We've been running into this question ourselves without finding a distinct boundary.
Blur < 5px and offsets < 2px seemed to be approximations.

Disabled text input placeholder in [OOjs UI](https://github.com/wikimedia/oojs-ui/) at 400% zoom

[dylanb]

@DavidMacDonald how did you determine that the contrast was sufficient using the shadow?

@Volker-E (side note: disabled elements do not have to meet the contrast minimums)

[DavidMacDonald]

That's where I use the Colour Contrast Analyser eyedroppers :)

[dylanb]

@DavidMacDonald What I mean by that question is, what relationship between the font-size/weight and the shadow-size leads to the same ability to read the text at the threshold contrast ratio? Do you have any research that backs up the claim that the shadow contrast is equivalent to the same background color?

[DavidMacDonald]

In WCAG, there is no distinction between shadow and background. The text needs to have sufficient colour with its adjacent color (or outline) which we call background. When CSS shadow is used, it becomes the background as long as it is 1px. See Note 5 on the definition of contrast ratio

[dylanb]

@DavidMacDonald how do you determine whether the shadow definition actually results in a background that is at least 1px wide around the entire letter?

[WilcoFiers]

@DavidMacDonald I don't think it's quite as easy as you're saying it. Check out this codepen:
https://codepen.io/wilcofiers/pen/Kmxrra

In theory, all of these meet the color contrast, if you take the color of the text-shadow in place of the background. But offset and blur radius impact that quite a bit. Can you make a suggestion on how to deal with those?

[DavidMacDonald]

I agree, it would take some clever programming, and no one has done that before... some investigation of threshold blur etc... it would make you guys rock stars :)

This is not a simple bug fix, and may be a future investigation. But it is possible to test manually with eyedroppers, so perhaps it can be done automatically.

Perhaps a short term solution is to say something like "failure of contrast, shadow is being used which may cause it to pass, manual check necessary..."

[dylanb]

@WilcoFiers @marcysutton WDYT - should we turn this into two different tickets:

1. look for a shadow and place it into review items
2. longer term, research looking for shadow width and doing this totally automatically

[WilcoFiers]

Nah. I think we can take this on in one go. I just have to figure out how to come up with a percantage of how much of the shadow's color we should mix with the background color. WCAG doesn't give us anything for that, but we can just put together a few examples and give those the numbers we feel are reasonable.

[DavidMacDonald]

the other trick is to ensure it's a 360 degree shadow, which requires two shadows, because it has a right left offset and a top bottom offset.

[tlobinger]

+1 on solving the issue

I think it should be easy/easier to calculate the merged colors if the assumption is the shadow is applied without offset. In that case the gradient can be calculated and what should matter is the color of the first pixel merged on top of the background. This new color becomes effectively an outline of the text..

So I would suggest for now to ignore shadow offsets and solving the issue for gradient backgrounds.
So limit the solution to solving this case https://jsfiddle.net/aq9Laaew/51325/

[dylanb]

@tlobinger I agree this would be a good first case to solve-for

@WilcoFiers comments?

[gulzarsingh591]

I am facing a similar issue while validating the text color(foreground) with text shadows(background) using axe.
In my case, we need to maintain the brand colors as well as the A11y contrast ratio. So to achieve both, we are referring a G18 technique which w3c is recommended. It says

If the background or the letters vary in relative luminance (or are patterned) then the background around the letters can be chosen or shaded so that the letters maintain a 4.5:1 contrast ratio with the background behind them even if they do not have that contrast ratio with the entire background.

Here is the link - https://www.w3.org/TR/WCAG20-TECHS/G18.html

Not sure if your tool is programmed to pick the text shadows as background. Is the axe tool updated with this enhancement?

[WilcoFiers]

Here's another example of this:

Source: https://act-rules.github.io/rules/afw4f7#passed-example-4

<p style="color: #000; background: #737373; text-shadow: white 0 0 3px">
	Some text in a human language
</p>

[padmavemulapati]

Verified with the latest axe-core(3.5.5) code base ,
testfile - `

Some text in a human language

` also verified on test file ` Hello world <script> window.addEventListener('load', function() { var span = document.getElementById('span') var style = window.getComputedStyle(span) console.log(style.getPropertyValue('text-shadow'))

});

</script> `

[jeankaplansky]

included in internal release notes 7/27/2020