Bug 277290 - AX: Scrolling containers inoperable with keyboard
Summary: AX: Scrolling containers inoperable with keyboard
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: Safari 18
Hardware: All All
: P2 Critical
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2024-07-29 15:46 PDT by Adrian Roselli
Modified: 2024-07-30 23:44 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Roselli 2024-07-29 15:46:09 PDT
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.
Comment 1 Radar WebKit Bug Importer 2024-07-29 15:46:19 PDT
<rdar://problem/132760015>