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

[odaimkh]

Scrollable content can be reached with sequential focus navigation. <-- is sequential focus still ensured?

This rule applies to any HTML element that has visible children in the flat tree, and for which at least one of the following is true:

the element has a horizontal scroll distance greater than the computed left or right padding of the element;
the element has a vertical scroll distance greater than the computed top or bottom padding of the element.
For each target element, at least one of the following is true:

the element is included in sequential focus navigation; or
the element has a descendant in the flat tree that is included in sequential focus navigation; or
the element is inert.

my question in this regard what is scanned for this rule ? only the element or does it also handle the other 2 options ie. the elements children ?

[straker]

@odaimkh The rule looks at all elements on the page (except select and textarea). If an element is found to be a scrollable and is larger than the scroll area, the rule will check the element's children for a focusable element, or if the element itself is focusable or inert.