[X] I have tested the issue with the latest version of the product
Issue Description
isVisibleOnScreen's overflowHidden check currently treats elements as hidden if they are contained within an overflow: hidden ancestor whose bounding box does not overlap with the element under test.
However, this isn't quite accurate if an outer container uses overflow: hidden but contains an intermediate container which uses overflow: auto, which then contains the element under test. In this scenario, an element which is scrolled far out of view might be treated as "overflow-hidden" based on the outer container, even if it is scrollable into view via the intermediate container.
In the motivating example, this pattern of containers is used to implement "sticky header" functionality: body has overflow: hidden applied, the sticky header appears statically within the body, and then the rest of the page is rendered within a overflow: auto intermediate container. This results in false negatives against content "below the fold" in the intermediate container for any check whose matches includes a isVisibleOnScreen conditional.
Expectation
In the pattern described above, isVisibleOnScreen should treat an element scrolled out of view in the intermediate container the same as it would treat an element scrolled out of view in a page with no custom overflow styling.
Actual
In the pattern described above, isVisibleOnScreen treats elements scrolled out of view as "not visible", where it would have treated the same element scrolled out of view on a page not using such a pattern as "visible".
The repro steps in the linked codepen use label-content-name-mismatch as a test case - it is one example of a rule which only matches elements that are isVisibleOnScreen, but probably not the only one.
Product
axe-core
Product Version
4.6.3
Latest Version
Issue Description
isVisibleOnScreen
'soverflowHidden
check currently treats elements as hidden if they are contained within anoverflow: hidden
ancestor whose bounding box does not overlap with the element under test.However, this isn't quite accurate if an outer container uses
overflow: hidden
but contains an intermediate container which usesoverflow: auto
, which then contains the element under test. In this scenario, an element which is scrolled far out of view might be treated as "overflow-hidden" based on the outer container, even if it is scrollable into view via the intermediate container.In the motivating example, this pattern of containers is used to implement "sticky header" functionality:
body
hasoverflow: hidden
applied, the sticky header appears statically within the body, and then the rest of the page is rendered within aoverflow: auto
intermediate container. This results in false negatives against content "below the fold" in the intermediate container for any check whosematches
includes aisVisibleOnScreen
conditional.Expectation
In the pattern described above,
isVisibleOnScreen
should treat an element scrolled out of view in the intermediate container the same as it would treat an element scrolled out of view in a page with no customoverflow
styling.Actual
In the pattern described above,
isVisibleOnScreen
treats elements scrolled out of view as "not visible", where it would have treated the same element scrolled out of view on a page not using such a pattern as "visible".How to Reproduce
Codepen demonstrating same content with different results depending on use of sticky header pattern - see repro steps embedded in page.
Additional context
The repro steps in the linked codepen use
label-content-name-mismatch
as a test case - it is one example of a rule which only matches elements that areisVisibleOnScreen
, but probably not the only one.