Axe-core: get-background-color Does not reset horizontal scroll

Created on 18 Dec 2019  路  7Comments  路  Source: dequelabs/axe-core

summary

https://github.com/dequelabs/axe-core/pull/1845 was merged & released to

[check] if the center point of the element is within the viewport and if not, look for a scrollable parent element and scroll it.

This feature introduces the bug where it does not reset the horizontal scroll after the test is complete.

Expectation:

Horizontal content is scrolled and is restored to its initial state.

Actual:

Horizontal content is scrolled and is not restored to its initial state.

More Info

We use axe to run accessibly and visual regression on test pages. The following screenshot shows the before (deleted) and after (added) visuals. Before is running axe 3.2.0 on the page then taking a screenshot. After is running axe with 3.4.0.

Screen Shot 2019-12-18 at 4 22 55 PM


axe-core version: 3.4.0
~axe-webdriver, extension or other integration version: X.Y.Z~

Browser and Assistive Technology versions

For Tooling issues:
- Node version: v10.17.0
- Platform:  Mac
color contrast core fix

Most helpful comment

Thanks for letting us know. We're working on a major change to the color-contrast rule should fix this issue.

All 7 comments

Thanks for letting us know. We're working on a major change to the color-contrast rule should fix this issue.

@straker After taking a closer look at the cause of the issue presented in the above screenshot, it is not #1845 that introduced the issue. It was the change made on #1599 that caused this. I tested our application without that change and I continue to get the before (deleted) screenshot and our tests passed. Once I included the check for the hidden overflow style from #1599, then I get the after (added) screenshot.

Our application has another test example that also failed because the overflow style on its element is hidden. It appears to me that these hidden overflow elements initially get scrolled to a different position but do not get restored back to the original top-left position because the scrollableX and scrollableY variables here no longer evaluate to true

I don't know what is the best way to fix this. #1599 was for fixing issue #1730. Is there another potential solution to address #1730?

ID'd as color-contrast issue. We're going to make one entry into the release notes for all color-contrast fixes/enhancements.

@jeankaplansky @straker Would it make issue tracking easier if I log a separate issue for the root cause of the issue I mentioned above relating to the changes made in #1599? The color-contrast fixes/enhancements you're making would not fix the issue this issue.

Ya, this issue has already been flagged as fixed, so probably best to create a new issue to track it.

@straker @jeankaplansky I logged #1979 to restore scrolling for elements with hidden overflow style. Can you please review and prioritize as this issue is preventing my team from upgrading to V3.4.0 to fix other issues?

Larger pages also not taking more than 11s , attached screenshot
image

Was this page helpful?
0 / 5 - 0 ratings