"Scrollable region must have keyboard access" with focusable elements within

[gportela85]

Product

axe-core

Product Version

4.10.3

Latest Version

• [x] I have tested the issue with the latest version of the product

Issue Description

Expectation

No warnings about scrollable regions needing keyboard access.

How to Reproduce

Open https://plnkr.co/edit/IyLmkiUknP2hB8jT?open=main.js&preview Click the arrows at the top right to show the example in a separate window Run the Axe Extension to scan the page.

Additional context

This grid is wrapped with a "tab guard" element (tabIndex 0) that manages which cell needs to be focused when the grid is focused, and then the cells (tabIndex -1) will scroll the grid with a custom scroll logic while moving focus across cells.

[straker]

Thanks for the issue. After looking at the example, I can see that each of the cells have tabindex=-1 on them. I think what we want to do is determine if a child is programmatically focusable (i.e. has tabindex=-1) and if so, return needs review for the element rather than a violation. This would be similar to our approach for https://github.com/dequelabs/axe-core/issues/4788.

[DanteGagne-Deque]

Looks like this is connected to a customer reported issue: https://dequehelp.zendesk.com/agent/tickets/43734

[fschroiff]

We are getting a (I believe) false positive as well on e.g. this page: https://level-level.com/werk/international-film-festival-rotterdam/

The container with images is focusable and scrollable with arrow keys.

[WilcoFiers]

@fschroiff The scroll containers on that page are made focusable by the browser. Used to be that only Firefox did this. Chromium was updated recently to behave the same way Firefox does. That's fantastic news for keyboard accessibility, but Safari doesn't yet do this, and so the issue still persist, and is now often overlooked by testers who prefer Chrome or Firefox.

I would still call this a false positive because of the buttons, although those are kind of a pain to use in Safari as well. To make those buttons inactive they are replaced. This causes Safari to lose focus and move it back to the top of the page. That's a frustrating enough thing that it's somewhat debatable whether that passes WCAG. That's irrelevant to this issue though.

@straker we should make it clear in this rule's message that this is specifically a Safari issue. Far too easy to overlook the problem otherwise. We've talked before about looking at heuristics of scroll containers that likely have buttons, that should avoid the false positive Florian reported too.

[YuriScarbaci]

We've talked before about looking at heuristics of scroll containers that likely have buttons, that should avoid the false positive Florian reported too.

Would such heuristic you mention also take care of role spinbutton/type number and other aria-roles and semantics that are expecting the up/down arrow in their standard behaviour to not scroll the container (the menu button that opens the menu, the selects that open the context region, etc...) ?

[WilcoFiers]

@YuriScarbaci I would not think spinbutton is appropriate for that kind of a control. I get the idea, since you are "spinning" the carrousel, but spin buttons are intended for changing a form value up and down, not for controlling a user interface. Whether that'd qualify as a WCAG failure I'm not sure though. That feels like an edge case to me. We'll keep it in mind when we pick this up.

[YuriScarbaci]

just a question regarding this kind of issues,

Does the axe-core team prefer to have false-positives or false-negatives?

This may sound like a dumb question but if such scenarios are "edge cases" knowing what axe-core teams prefer to address does shape how CI&CD checks should be treated moving forward

I personally would love to be able to configure it somehow so rules that are kinda difficult to check for like the scollable region one can be toggled accordingly until proper fixes comes from you

[WilcoFiers]

We try to avoid false positives as much as possible. This rule in particular has been a bit of a problem. Initially this worked very well, but new features in CSS has made it so that devs are now increasingly just using CSS scroll controlled with buttons. That'a s cause of false positives.

I suspect that if we can't figure out a good solution this rule may have to be switched to only reporting needs-review results.

As for turning individual rules off, I believe this is possible in all test integrations that Deque maintains. This is the syntax to do it in axe-core directly:

// source: https://github.com/dequelabs/axe-core/blob/develop/doc/API.md#options-parameter
axe.run(
  {
    rules: {
      'color-contrast': { enabled: false },
      'valid-lang': { enabled: false }
    }
  },
  (err, results) => {
    // ...
  }
);

[YuriScarbaci]

As for turning individual rules off, I believe this is possible in all test integrations that Deque maintains. This is the syntax to do it in axe-core directly: {...}

that's great, thanks for sharing!

What about the google chrome plugin? any way to make that mute some rules?

Initially this worked very well, but new features in CSS has made it so that devs are now increasingly just using CSS scroll controlled with buttons. That'a s cause of false positives.

and also with https://github.com/dequelabs/axe-core/issues/4914 patterns that by nature are relying on "pseudo focus" instead of actual focus and handling the scrolling "as expected via javascript"

This rule in particular has been a bit of a problem. [...] I suspect that if we can't figure out a good solution this rule may have to be switched to only reporting needs-review results.

Given Chrome have put their own heuristic as well as firefox to make it work even when actual code doesn't implement it, even if safari is lagging behind, I think switching the rule to reporting "needs review" isn't such a bad idea regardless, it would also let the final application choose if they prefeer to rely on a native browser implementation if that makes sense to them (e.g. the webapp is meant to never be used in Safari and is built specifically for a specific browser or whatever, in a "IE 11 not supported banner" like manner )

[WilcoFiers]

There is no way in the axe extension to disable individual rules. We do have plans to add an option to ignore issues in the axe Extension, but that isn't ready just yet.

I think for the next minor version this rule needs to be switched to needs review only.