Color contrast does not work when pointer-events: none is set on the element

[EXPErfleischmann]

When using aXe on our site, the color contrast does not fail because the element has pointer-events:none set on the label. This makes it very hard to verify color contrast as we have pointer-events set to none in numerous places.

[marcysutton]

I don't quite understand this issue. Are the items legitimate color contrast violations, but they aren't failing in axe-core because of pointer-events: none;? Or they are failing, and you can't debug from the aXe extension with right click and "Inspect Element" due to pointer-events?

Can you provide a demo for this issue?

[EXPErfleischmann]

@marcysutton sure! The items are color contrast issues but aXe isn't marking them as failures.

I created a code pen: https://codepen.io/rfleisch/pen/JNEzMP

If you remove the pointer-events: none from the less you will see the failure when you run aXe, when you add it back in, you will not see the failure.

[marcysutton]

Ah, yes that is reproducible–thanks for the quick reply. I bet pointer-events: none excludes the element from document.elementsFromPoint. We might have to do an extra check on an element for that condition and add it to the element collection, hopefully it doesn't slow that rule down even more.

From MDN:

pointer-events: none - The element is never the target of mouse events; however, mouse events may target its descendant elements if those descendants have pointer-events set to some other value. In these circumstances, mouse events will trigger event listeners on this parent element as appropriate on their way to/from the descendant during the event capture/bubble phases.

Because of the ability to override on descendant elements, this seems valid from a high level. However, I question the interaction/accessibility implications for pointer-events: none on a label element; is there more to it than that? We exclude disabled elements, can you describe the use case some more for wide use of pointer-events: none; on a website? I haven't ever had a need for it that much unless some kind of hack is involved.

[dylanb]

pointer-events:none on a label is a bad idea because it disables the functionality of being able to click the label to focus the field (or toggle the checkbox, or select the radio button)

However, that does not mean that we should not try to fix this problem.

[EXPErfleischmann]

@dylanb @marcysutton I looked into why we are using pointer-events:none on a label and it is because if a label overlaps with an input, a click event wasn't getting triggered on the input.

[dylanb]

@EXPErfleischmann you are still making the experience worse, you should rather fix the overlapping label problem

[scurker]

Been digging a bit into this, and have a codepen demonstrating the issue:

• elementsFromPoint() excludes element and descendants with pointer-events: none
• elementsFromPoint() can include descendants of pointer-events: none with pointer-events: auto

This behavior is consistent across browsers, and is part of the spec. Since the spec uses hit testing to derive the stack, pointer-events: none are excluded from the element stack.

The elementFromPoint() method does not necessarily return the top-most painted element. For instance, an element can be excluded from being a target for hit testing by using the pointer-events CSS property.

Thinking about how we implement color contrast and talking with @straker, I'd be concerned about adding more expensive calcs to determine the background color since the color-contrast rule is already one of our slowest rules. I thought about trying to find elements with pointer-events: none and swap them to auto, but that could be pretty expensive considering the rule runs per element.

[AutoSponge]

Temporarily setting:

* {
  pointer-events: all!important;
}

Should allow us to ignore this issue.

[jeankaplansky]

captured in release notes 2/03/2020

[padmavemulapati]

as per fix for larger sites its not taking more than 13sec, and events are working as expected.