AGWG feedback: Scrollable element is keyboard accessible

[WilcoFiers]

Source: https://www.w3.org/2002/09/wbs/35422/act-dec-2022/results#xq9

From Gregg Vanderheiden:
Maybe I am missing something -- but I do not see that this test in any ways tests whether the Scrollable element is keyboard accessible/usable. Only that it is keyboard focusable (or elements in it are)
This could be that I misunderstand what a "scrollable element" is -- but it is defined in the materials and I don't see how the test ensures that I can fully scroll it from the keyboard (visually as well as functionally)

From Gundula Niemann
I understand a rule does not necessarily yield a complete test, is that correct?
That is, passing does not mean compliance with the corrsponding SC?
In that case I approve.

[WilcoFiers]

ACT Task Force Response (approved)

We have updated the rule's title to "Scrollable element is included in the sequential focus navigation" to more clearly indicate its limited scope. This is further explained in the background section of the rule. ACT Rules are designed to be atomic tests. They are written to test a single aspect of an accessibility requirement, in a single technology. This has a variety of benefits, and follows general best practices in software testing.

A single ACT Rule thus is (almost) never a complete test of a WCAG success criterion. The precise relationship between the ACT Rule and other accessibility requirements (mostly WCAG and ARIA) are described in the "Accessibility requirements" section in each rule. There you can see that failing the rule means the relevant success criterion is not satisfied, but that a passed or inapplicable outcome on the rule requires further testing.

That ACT Rules be kept atomic is a requirement from the ACT Rules Format. While we can, and intend to write more rules to cover more aspects of different WCAG success criteria, we do not believe that the lack of a different rule should prevent us from publishing.

[tbostic32]

I know we have repeated some of this verbiage about ACT rules being atomic tests and testing for failure, but I think this response in particular could do with another sentence or two specifically responding to Gregg's comment. As it is right now, it comes across as just pointing out the specific parts of the format relevant to the discussion here and then making AGWG draw the conclusion. I think we should add a sentence or two specifically describing how these section show that we don't need to address Gregg's comment.

[kengdoj]

I think Gregg may be looking for the rule to include using the arrow keys to scroll. Suggest pointing to the Background as part of the response:

To ensure there is some element from which arrow keys can be used to control the scroll position, focus must be on or in a scrollable region. If scripts are used to prevent the keyboard events from reaching the scrollable region, this could still cause a keyboard accessibility issue. This must be tested separately.

[WilcoFiers]

We should update the rule title: Scrollable element is included in the sequential focus navigation

[scottaohara]

Sorry, but this now seems to me to be saying that a scrollable container needs to be in the sequential focus order, regardless of whether there are interactive elements within it which would have allowed it to be scrollable. Is that the intent?

The previous wording of the rule/description seemed more open to the fact that one shouldn't need to make containers focusable so long as the container itself could be scrolled per nested focusable elements.

[mraccess77]

I agree that the rule could just be about the scrollable area or it's descendants being focusable in sequential navigation to allow for scrolling but not actually address scrolling. However, much of the rule including it's description says more "This rule checks that scrollable elements can be scrolled by keyboard". This description seems to not address whether it's in the focusable navigation order but just whether it can be scrolled with the keyboard. I'm ok if the rule covers both situations in which case it seems like we just need to make it clear that it covers both focusing and scrolling.

I also agree with Scott that the proposed name change only muddies the issue as it then implies you can't rely on a focusable descendant for scrolling.

[WilcoFiers]

@scottaohara @mraccess77 I see where you're coming from. Could you propose a different title to use?

[mraccess77]

The current name seems sufficient to cover both reaching the area or it's descendants with the keyboard and scrolling the area with the keyboard.

If we want to cover both, the description could be updated to something like "This rule checks that scrollable element or an interactive descendant is in the navigation sequence and the scrollable area can be scrolled using the keyboard"

[WilcoFiers]

The rule doesn't test if scrolling is blocked. That would have to be a separated rule perhaps. @scottaohara @mraccess77, would updating the name and description to this address your concerns:

name: Scrollable content can be reached with sequential focus navigation
description: |
  This rule checks that scrollable elements or their descendants can be 
  reached with sequential focus navigation so that they can be scrolled
  by keyboard

[mraccess77]

@WilcoFiers that name is fine with me - if possible it could be helpful if we also put a statement in the rule to clarify that this rule does not address whether the area can be scrolled or not - after reading 5 times I now understand that - but it was not obvious to me the first 4 times reading it - so others could be confused as well.

[WilcoFiers]

Excellent, I will make those changes then. The rule already mentions that further testing is needed in the background. Can you suggest what more would be needed here:

Background

To ensure there is some element from which arrow keys can be used to control the scroll position, focus must be on or in a scrollable region. If scripts are used to prevent the keyboard events from reaching the scrollable region, this could still cause a keyboard accessibility issue. This must be tested separately.

[WilcoFiers]

Response has been accepted with the amended rule.