Set scrollable-region-focusable impact to serious

[WilcoFiers]

The scrollable-region-focusable is currently at moderate. I think we made a mistake there, this can result in people unable to view content they need to view. Setting it to serious makes this consistent with the impact of frame-focusable-content, which is very similar.

While problematic, I don't think this quite reaches the level of critical, because copy/paste can still get you the content, and some clever use of a browser's search function can also function as a work-around.

[padmavemulapati]

Validated with the latest axe-core develop branch code base, scrollable-region-focussible rule impact now is serious earlier it was moderate

[patrickhlauke]

I'd like to bring a counterpoint here: would keyboard-only users not have caret browsing enabled as well? As in, they're not just reliant on tabbing, but also use a caret (to do things like text selections etc), and with caret browsing overflow:… regions can be scrolled. /cc @scottaohara

[WilcoFiers]

@patrickhlauke Interesting idea. I think that would still fail. It's debatable though. If caret browsing was the only way for a keyboard user to activate a link or button I think that would fail 2.1.1 Keyboard, so by that logic scrolling would too.

The SC has no "if a mechanism is available" exception like some others do. I generally understand that to mean the default mode of operation needs to be pass, not some thing you can turn on if you know to find it. You don't pass 2.4.7 focus visible just because there might be some accessibility feature in your browser, or in some extension you can turn on to get a better focus.

[patrickhlauke]

It's borderline though, because arguably caret browsing is (likely?) the default mode of operation for a pure keyboard user (as otherwise, how would they do normal actions like selecting text to copy/paste etc). Even regular scrolling of an entire page doesn't happen purely because the page container as a whole is focusable. Of course, without much data on the topic, it's a tough call...but certainly worth keeping in mind though.

[scottaohara]

the problem i've faced a lot with this sort of rule is that when content only has an overflow due to a smaller viewport size, the ask to tell developers to make that container focusable only when needed is far easier said than done.

So instead, we get developers putting tabindex=0 on elements because they have the potential to be scrollable, but won't always be. For larger viewport sizes the experience is degraded because keyboard users have to navigate through a bunch of focusable containers for no reason. People using screen readers similarly have to put up with such unnecessary focusable elements - and if someone has also decided "ah, it is focusable thus it must have a role and name!" then we get a bunch of junk like "scrollable container, group" - and that's if we're lucky and the developer is concise with their name/role. So now screen reader users have to hear "scrollable container, group" for various instances of content - which again might not actually be scrollable because of the viewport size

This is really something that would be far better handled by user agents rather than making developers do this. E.g., firefox already making their scrollable containers focusable. Chrome/Edge Canary has implemented focusable scrollable containers if they lack focusable descendants - and they are not focusable if there is a child tabbable element. This is even better than what a web author would probably do on their own (EDIT: I was just informed this is likely shipping to stable within the next few versions). Safari is the odd duck out here - but this is also assuming that such content is completely keyboard inaccessible - which is not true. Yes, if a container does not have tabbable content within it, then it cannot be reached by tab key alone. But this also assumes that someone is 100% using a keyboard and somehow isn't either using some sort of other assistive tech to help them navigate / create pointer events, or be able to perform a single mouse click on their own, which when clicking anywhere in the scrollable container (which does not have to be precise for those with motor disabilities), then up/down arrows work just fine.

tldr;
i agree there are usability issues for sure here, and the fact that not all user agents are on the same page (though as mentioned, 2 of the 3 major browser engines have either a solution or a solution on the way) can make this frustrating for some users. However, a rule implying that this is something authors need to fix as a serious issue has a high probability to lead to degraded user experiences for the instances i mentioned of scrollable containers only existing at certain viewport sizes - as well as the aural UI noise that this creates.

Specifically, regarding this bit:

The SC has no "if a mechanism is available" exception like some others do. I generally understand that to mean the default mode of operation needs to be pass, not some thing you can turn on if you know to find it.

I would tend to agree if not for the fact this is exactly what someone needs to do if they're using macOS - since under their default keyboard settings one cannot use tab to navigate to all tabbable elements of the web page. One needs to know they must press Option + Tab to do this, or to specifically turn on the feature to have Tab reach all tabbable elements. Yes, not apples to apples with scrollable regions. But neither is the comparison of scrollable regions to links/buttons - since the latter two have long been expected to be reachable via standard keyboard navigation, whereas scrollable regions have not.

All that said, this is my opinion on the matter which is shared by others (with and without disabilities) I work with, but I am not speaking for Microsoft's official stance here, at this time. I am quite open to actual user opinions / experiences on this to rebut my pov. However, as I have been dealing with issues specific to this over the last few years at scale, I have not yet encountered a 100% keyboard user who has had significant difficultly with such content (in that they are either using caret browsing, or can perform a single click into the scrollable field with their pointer device to then allow them to use arrow keys to scroll), nor an author implementation that hasn't resulted in the degraded UX for other situations/users I've mentioned.