search

dequelabs / axe-core

Accessibility engine for automated Web UI testing
https://www.deque.com/axe/
Mozilla Public License 2.0
5.75k stars 746 forks source link

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

Open v-viyada opened 1 month ago

v-viyada commented 1 month ago

Product

axe-core

Product Version

4.8.4

Latest Version

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 https://github.com/squidfunk/mkdocs-material/issues/7193 and https://github.com/microsoft/accessibility-insights-web/issues/7338 for additional details on the issue.

jzazo commented 1 month ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 1 day ago

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