Include position absolute elements in tap targets audit

[mattzeunert]

Right now all position absolute tap targets are ignored by the audit so we don't falsely report failures where elements have the same x/y position but a different z-index. For example:

But ignoring them also misses real failures. To include them we need to detect whether an element is actually visible and we think we can use elementFromPoint to do that:

• we can treat a target as invisible if the topmost element at its center point isn't part of the tap target
• elementFromPoint only works within the current viewport, so we need to scroll through the page screen by screen in the gatherer

The axe gatherer already scrolls around the page, so that seems fine?

There might be a way to manually calculate if an element is in the top layer, but elementFromPoint seems easier to use and I think it would also allow us to get rid of filterClientRectsWithinAncestorsVisibleScrollArea.

@patrickhulce @brendankenny What do you think?

[tmb-github]

I have a fixed header with anchor links, and a main page with tap targets in different locations that scroll with the rest of the main page content. When I run Lighthouse 4.2.0 on Chrome Canary Version 75.0.3737.0 (Official Build) canary (64-bit), Lighthouse misinterprets the links on the fixed header as being on top of / too near tap targets on the page. Presumably, Lighthouse scrolls down the page during the audit, and during the scroll, it compares the location of the anchor links on the fixed header with the tap targets on the main page. This means that when parts of the page with tap targets are still in the window but below the fixed header (i.e., the tap targets are no longer visible or interactable, because they're under the fixed header), it misinterprets the no-longer-visible tap targets of the page proper as coming too close to the visible anchor links of the fixed header.

Importantly, this result obtains when I have the Developer's Console docked to the right (the standard location), with a window display of 850x687. This causes all of the anchor links on the header to register as conflicting with tap targets on the page proper. If I dock the Developer's Console to the bottom, only 1 of the anchor links in the header conflicts with a tap target on the page proper.

Run the SEO audit on this page to see it in action: https://ives-fourth-symphony.000webhostapp.com/ron-sanford/view-our-work/

[mattzeunert]

Hey there! Thanks for reporting this. I tried replicating it at that window size, but didn't get a failure (same Chrome version as you):

Position fixed elements should be excluded from tap target collisions. Are you getting this consistently? It might help if you can share the Lighthouse report (click the "Download report" button in the top left of the Audits panel).

[tmb-github]

Today I'm able to reproduce the error when I dock the Developer's Console at the bottom of the screen. See attached pic & JSON report from Lighthouse.

JSON: https://gist.github.com/mattzeunert/49678bef707665da7f995500e8833e8c
Report: https://googlechrome.github.io/lighthouse/viewer/?gist=49678bef707665da7f995500e8833e8c#seo

[mattzeunert]

Thanks @tmb-github!

I still can't quite replicate it, but I have a feeling that it depends on how quickly the images load or if you scroll on the page during the Lighthouse run.

The underlying problem here is that while we ignore position absolute and position fixed, we don't ignore position sticky. Will fix that.