dequelabs
ColorContrast - Antialiasing can cause false positives
The ColorContrast algorithm can become confused by antialiasing, depending entirely on the framing rectangle. If midpoint of the bounding rectangle happens to land on a scanline with lots of antialiasing pixels, the colors are misidentified based on the antialiasing pixels.
I've created a fork that demonstrates the behavior. To demo, clone https://github.com/DaveTryon/axe-android/tree/AntiAliasingBugDemo and run the color contrast tests. I've added 2 tests:
- In
imageTest_antialiasingBug_937_Succeeds, the middle scanline has very few antialiasing pixels, and the algorithm correctly identifies it as black test on a white background. - In
imageTest_antialiasingBug_938_Fails, the bounding rectangle is only 1 pixel larger, but it causes the middle scanline to intercept lots of antialising pixels, and it reports the foreground text color as ff9a9a9a instead of ff000000.
Since Views can be of any size, this has the potential to trigger false positives in many different contexts.
Screenshot Here's a screenshot of a portion of the test image--it clearly has no contrast issues as an image, but when we get unlucky about the reported bounding rectangle, the rule flags it as an error.
Why the Control is Accessible This is black on white--contrast is 21:1, which is as high as it can get. Visually, you need to zoom to about 400% before the antialiasing is even perceptible to the eye, but the algorithm happens to get unlucky. One option might be to require consistent results from multiple scanlines before assigning a high confidence result
This sounds like a heuristics problem. We probably just need to update some configurations for how Android is rendering things now. Basically, we need to expect that acceptable "ColorTransitions" are thicker than we once did. This isn't difficult to fix, but may require us to update each of our test cases from a modern android device.
@DaveTryon is the "Latest Alerts" image here a screenshot from your device? How is this captured?
@chriscm2006, Yes this was a screenshot from my device. By bad luck, the text in the view was positioned such that the midpoint (the first scanline) went right down the antialiased bottom scanline of the text--that's one of the unit tests I added.
I'll have to wait to see your change to the transition thickness, but my gut is that an algorithm that can reach a high confidence conclusion on a single scanline will always be subject to false positives in certain geometries.