Incomplete color-contrast check

[muan]

Reference: #1539 and #1185.

We are observing a flaky color-contrast check that gets triggered due to viewport size changes. Initially we were using v3.1.2, and got the error in #1185.

I have now created a reproduction case with v3.3.1, see https://html-is.glitch.me/axe-core-color-contrast.html. In Chrome, these are the results I am getting:

When viewport width is 800px, 1 incomplete check is reported.

When viewport width is 850px, 1 violation and 1 incomplete color-contrast check are reported.

When viewport width is < 760px or > 900px, 1 color-contrast violation is reported.

The expected result is there should always be 1 color-contrast violation reported on this page.

I tried to debug this, and it comes down to the scrollIntoView call.

When axe-core calls scrollIntoView on the sidebar <span> element at 800px & 850px, nothing happens, because the element is partially visible already. This breaks the check because the element contains a child element which is outside the viewport. Changing the scrollIntoView call to (https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView):

elm.scrollIntoView({block: alignToTop ? 'start' : 'end', inline: 'end'});

fixes the issue, as it will ensure that the element is always scrolled fully into view if possible.

I'm not sure what browser compatibility is required of this check for axe-core, and in Safari I actually consistently get Element's background color could not be determined because it partially overlaps other elements regardless of viewport size. So the fix would definitely require a deeper look.

[straker]

Thanks for helping us better find where color-contrast is being a bit flaky. We'll have to figure out what exactly is going on, and now that we have a reproducible test case it will help us a lot.

[straker]

So it looks like there's two different problems. The first is as you identified in that we need to scroll the element fully into view before we check for it (including horizontal scrolling). The second seems to be that Safari does not add the span parent tag of the button from the elementsFromPoint API, thus making it seem like there's a span overlapping the button in our checks.

[haonliu]

we've experienced the same issue and tried the fix suggested by @muan and it works!

[jeankaplansky]

Include the title of this issue associated with the title/link to https://app.zenhub.com/workspace/o/dequelabs/axe-core/issues/1845 in release notes.

[chandana7393]

Tested, working as expected.

CC: @somaalapati
Tested Environment:
Axe-coconut - 4.0.0.29004v
Chrome - 77.0.3865.120v
OS - Windows 10 64 bit.

[devaradhanm]

This issue is not yet fixed in 3.4.0. We have added a sample test that you can use to validate this here - devaradhanm/axe-puppeteer@ac3d4d5
We also validated that this test passes once we add the fix suggested by @muan
elm.scrollIntoView({block: alignToTop ? 'start' : 'end', inline: 'end'});

[straker]

@devaradhanm Can you provide a codepen that shows the problem? Stackoverflow shows 49 color contrast bugs for me but it's a responsive site that doesn't seem to have horizontal overflow at different sizes.

Testing the OPs pen using the latest axe extension at different screen sizes always shows 1 contrast violation. We can't solve the Safari bug in 3.4.0, but there are some changes being made to color-contrast for 3.5.0 that should solve that one.

Do note that elm.scrollIntoView({block: alignToTop ? 'start' : 'end', inline: 'end'}); is not supported in IE 11, so we had to instead write a workaround for the pr for this to work

[devaradhanm]

@straker , by manual scanning via browser directly, I wasn't able to repro it. I was able to repro this issue when using puppeteer. You could get the changes I made on axe-puppeteer fork repo & just run the test - devaradhanm/axe-puppeteer@ac3d4d5

[ferBonnin]

@straker did the repo provided in the fork worked for you?

[padmavemulapati]

I am not seeing any issue, tried with different viewport widths.. seeing only one voilation which is "Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds" .. @straker could you please confirm me anything else need to verify.