Pseudo elements without position:absolute not picked up by color contrast

[geebru]

Want to preface this report by saying I have tried to follow the work being done on testing text against backgrounds (in my case, a gradient) when they're applied via pseudo-elements and it sounds like it should work, hence me posting this bug.

I'm running axe-core through cypress-axe and running a base-level check on one of our pages. To verify the results I also run Firefox's accessibility inspector as well as the axe plugin (hooray cross verification!).

Our core pages include a large gradient banner with the title of the page over top in white: Screenshot of design

cypress-axe was returning a "Serious" level failure, which fails the test, and returned the following:

failureSummary: "Fix any of the following:↵  Element has insufficient color contrast of 1.08 (foreground color: #ffffff, background color: #f6f6f6, font size: 45.0pt (60px), font weight: normal). Expected contrast ratio of 3:1"
html: "<h1 _ngcontent-pma-c250="" id="contentTitle" tabindex="-1" class="main__title title-1"> Application configuration </h1>"

This was a bit surprising as #f6f6f6 is the core site background which to me means axe-core isn't seeing the more closely related ::before that houses the gradient: DOM sample screenshot

I get a matching failure in the axe browser plugin for Firefox, but Firefox's accessibility inspector itself is correctly identifying the gradient and testing against that: Firefox a11y inspector success screenshot

Expectation: Text against the gradient should be passing, or return 'needs review' at worst

Actual: Gradient background is being ignored and text is tested against the page background color

Motivation: The primary reason I wanted to log this is that the only way around this I've found is by disabling color-contrast checks when checking all pages. This is super far from ideal as contrast checks are a crucial part of the process. I thought perhaps the DOM layout of how we're structuring the page was the cause of failure, but FF's checker is able to "see" the gradient (unsure what they use internally) so I'm surprised axe is failing here.

Our app is mostly behind closed doors but I can try to replicate if need be but many of our issues stem from the way our app is setup and sometimes aren't possible to replicate outside of the environment (at which point we deal with oddities and move on). But I felt I should post this in case others have seen this happen or just to get more info on potential workarounds to this issue.

axe-core version: 4.0.2
extension version: 4.6.0
Firefox version: 83.0

cypress version: 6.0.1
cypress-axe version: 0.8.1
cypress Chrome version: 87

[straker]

Thanks for the issue. Axe-core 4.0.2 doesn't support pseudo elements, but that was somewhat patched in 4.1.0 where we can at least detect there is a pseudo element and mark the element as needs review (due to lack of browser APIs for pseudo element bounding size that's the best we can do).

[geebru]

@straker Ah - so while that work is somewhat patched in the latest version, said latest version of axe-core just isn't in the extension (or my Cypress plugin) yet? If that's the case I feel less bad about temporarily disabling certain tests (or ignoring the element) until I can give out 4.1.0 a go.

Thanks for the quick reply!

[dylanb]

@straker Should this be closed?

[geebru]

I was going to say yes, but I'm still having a similar problem that might not be an issue with axe-core but our setup.

Our system header is built using a grid, with the gradient header being "underlaid" via some fancy grid work.

The header features a small avatar with white initials over the same gradient, and axe is correctly marking it as needing review as it's above a pseudo-element background. But in my screenshot, it's failing as it's comparing the Dashboard text color (#fff) to the core background color of the app, which is #f6f6f6.

The setup includes our main container being a grid, with some gutters setup, and the header area gradient being applied by pulling it "behind" the content via some specific grid declarations.

I currently have our Cypress workflow to ignore this area while I waited on the 4.1.x update which included the pseudo-element check, but found this one area is still failing, despite there being a background gradient image in between the color axe thinks is the background color, and the text itself.

If y'all think this is a real weird outlier that's on us to resolve in a more expected way (and that axe is working as intended) I can look into that. But figured I would update this that in this situation, the test will still hard fail.

[straker]

Would there be a way to pull the relevant code into a public file or codepen I could look at? From the description I'm not sure why it would be failing as it should detect the pseudo element and mark it as needs review.

[geebru]

@straker Of course!

Full codepen is here - https://codepen.io/geebru/pen/gOgwmwm Ran axe (Chrome extension, axe-core 4.1.3) on the debug page and same failure - https://cdpn.io/geebru/debug/gOgwmwm/wQAPoGWEmpPr

If it helps at all - the grid underlay technique we're using is modeled after this - https://snook.ca/archives/html_and_css/overlapping-header-with-css-grid

[straker]

I see the problem. We only check pseudo element if the position is absolute since we assumed that was the only way to have the text overlay the element. The grid fancy work is an interesting technique. I would say this is something we should account for.

[geebru]

I had a feeling it had to do more with our odd technique here than an actual failure on axe's side - I'll keep ignoring that area for now but will keep an eye on the roadmap for an update. Thanks @straker (and @dylanb for reminding me I needed to follow up here 😄)!