[False Positive] "scrollable-region-focusable" with combobox/menu-button and aria-activedescendants patterns

[YuriScarbaci]

Product

axe-core

Product Version

4.10.3

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

Expectation

when some specific patterns or arias are present, like aria-activedescendant the scrollable region should not fail, assuming the developer did implement the expected pattern.

Actual

the tool laments a non-scrollable region due to scroll coming from javascript

How to Reproduce

menu-button from w3.org/WAI/ARIA/apg/patterns/menu-button with scroll and scrollIntoView()

Additional context

This is a tricky scenario, but it's a common and valid scenario
this also affect custom application "select" and "combobox" patterns, where the spawing menu contains a list of items that doesn't receive direct focus, only focus styling and are tracked via aria-activedescendent

https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/examples/menu-button-actions-active-descendant/

[YuriScarbaci]

One possible Idea that may work is

the same way your tool check the children elements for focus to see if any of the children is focusable
add an additional check, if the children has an id and if there is an element in the dom that has the aria-activedescendent pointing to any of the id in the scrollable region.

basically identifying a focusable element has the aria-activedescendent + the active descendent is within the scrollable region that is being analyzed for wether the scrollable region is violating anything

Potential risks:
a false-negative, the active descendent exist but the developer didn't implement the proper region scrolling (like missing the scrollIntoView() or something)
But I understand axe-core is not meant to catch everything, and the same would visually affect all users, so it's going to be likely catched by any QA flow.