False positive: scrollable-region-focusable: Elements with scrollable content must be accessible by keyboard.

[v-viyada]

Product

axe-core

Product Version

4.8.4

Latest Version

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

Issue Description

Expectation

Search results are accessible using keyboard up and down arrow keys so it should not flag it as failed.

Actual

Scrollable component accessible using keyboard up and down arrow keys is flagged failure for scrollable-region-focusable rule.

How to Reproduce

1. Go to https://microsoft.github.io/rats/
2. Download extension and FastPass run: https://accessibilityinsights.io/. The error relates to the search box. If you search commands you can scroll through results, so the error is probably a false positive. This extension uses axe-core for accessibility scan.

Additional context

Please refer squidfunk/mkdocs-material#7193 and microsoft/accessibility-insights-web#7338 for additional details on the issue.

[jzazo]

FYI, the author of mkdocs-material posted in the referred thread: "Yes, I believe this is a false positive in our case, but I don't think that this can or should be solved upstream, because the accessibility checker would need to execute JavaScript to learn that the search results can be navigated."

So maybe this issue is not possible to solve if the extension is not executing javascript.

[straker]

Thanks for the issue. After looking into it and talking with the team, we've decided that this is a false positive. The reason for that is that the element has a height of 0 and should be ignored from the rule.

[jzazo]

Even if the height is zero, if you ignore this rule for such case and when I open the scrollable search box, if it wasn't keyboard accessible you wouldn't be able to detect? I am not sure what the best solution would be, but maybe in this case the decision is whether to have false positives, or miss positives?

[yuri-scarbaci-lenio]

but maybe in this case the decision is whether to have false positives, or miss positives?

there is a third option maybe,

Would it be possible to create some kind of axe-core syntaxis to have the tool be able to detect that a specific rule is being respected even if axe-core is not able to actually confirm this statistically, for scenario like those?

Something like data-axe-core-false-positive="scrollable-region-focusable[, other-rules-identifiers-if-any]" that a developer can choose to specifically set in their own DOM for all those scenarios where a false positive would be a blocker? ( jest-axe CI blocking static analysis just to name one)

in case you want a RFC for this, I am okay with anything but false positives
the tool/task at hand already implies that manual validation and miss positives can and will happens, one more is better than a false positive IMHO