Bug 277290
| Summary: | AX: Scrolling containers inoperable with keyboard | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Roselli <aroselli> |
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Critical | CC: | andresg_22, dan, darin.senneff, robin, spell, swithinbank, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 18 | ||
| Hardware: | All | ||
| OS: | All | ||
Adrian Roselli
Abstract:
For containers that allow scrolling, a keyboard-only user cannot scroll the container.
To reproduce the problem:
1. Using Safari with FKA, go to https://cdpn.io/aardrian/debug/bGLrYBo
2. Size the window so the table is clipped and scrollbars appear below it.
2. Using _only_ the keyboard, attempt to scroll the table left or right.
What is the expected behavior?
I should be able to scroll the table so I can see all the columns.
What went wrong?
Unless the table has an interactive control within that can take focus, there is no way for a user to scroll a container using just the keyboard.
Does this work in other browsers?
Yes. Firefox has had support since version 4. Chrome added support this week in version 127.
More detail:
Mouse Keys is insufficient since it mimics a mouse interaction.
Today, authors must make the container focusable (`tabindex="0"`) to meet WCAG 2.2 SC 2.1.1 Keyboard, and then they must add an appropriate ARIA role and accName to satisfy SC 4.1.2 Name, role, value. Once WebKit treats scrolling containers as focusable, authors will no longer need to create verbose ARIA-driven patterns.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/132760015>
Adrian Roselli
Related:
web-platform-tests interop 2025:
#762: Keyboard focusable scrollers
https://github.com/web-platform-tests/interop/issues/762
Existing WebKit feature request:
#190870: Make scrollable element focusable
https://bugs.webkit.org/show_bug.cgi?id=190870
Michael Spellacy
Just adding my support here. Would love to see Safari finally address this.
Chris Swithinbank
Really hope we see some action here. Since Chrome finally fixed this in January, WebKit is the last holdout.
Darin Senneff
+1 for this. Have had bug reports filed internally for this exact issue, forcing our developers to remediate manually with ‘tabindex’. It really should be fixed at the browser level.
dan
See also axe-core's scrollable-region-focusable rule, which only still reports violations due to Safari not supporting this feature (https://github.com/dequelabs/axe-core/pull/4995)