Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add keyboard navigation to table #2172

Merged
merged 119 commits into from
Jun 25, 2024

Conversation

msmithNI
Copy link
Contributor

@msmithNI msmithNI commented Jun 6, 2024

Pull Request

🤨 Rationale

Resolves #1137

👩‍💻 Implementation

See #2173 for the most up-to-date expected behavior of keyboard navigation that this PR implements. (Direct link to updated HLD)

The KeyboardNavigationManager class does the bulk of the work:

  • Tracks what is currently focused / should be focused (via properties focusType, and row/column/cellContent/headerActionIndex)
    • Note: If the user clicks in the table away from the current keyboard focus, the focus state would end up out-of-date. There's code in handleFocus() to handle this (see additional comments there)
  • Listens for table keypresses to handle arrow key navigation, Tab/Shift-Tab, PgUp/PgDn/etc key presses
  • If the user unfocuses and refocuses the table, re-focuses the appropriate elements in the table (handleFocus() again)
  • Tab/Shift-Tab behavior should match the HLD / expectations for ARIA treegrid. (Basically, Tab/Shift-Tab go through the tabbable elements of the header row / current row, not including cells/column headers, until the end is reached, then the table blurs and elements before/after it will be focused with additional Tab presses.)

The overall approach of only setting tabindex=0 on the single element in the table we want focused is called roving tabindex.

To ensure that we control what elements in the table should get focused, this PR updates tabindex on many elements in the table:

  • The table itself is tabindex=0 to ensure that it can be focused via Tab
  • Elements that are focusable by default such as buttons/anchors, are explicitly set to tabindex=-1 to start with, until the keyboard navigation code wants to focus them (then they're set to tabindex=0 just before being focused).

🧪 Testing

  • Manual testing (mostly Chrome, some Firefox).
    • Earlier builds had some Safari testing, but we should explicitly re-test there before submission.
  • Added autotests

Keyboard navigation can be used on any/all of the existing table Storybook pages, once the table is focused.

✅ Checklist

  • I have updated the project documentation to reflect my changes or determined no changes are needed.

msmithNI added 30 commits April 3, 2024 23:01
- If an anchor is focused in a cell, and we're in the 'single interactive element' special case, and the user mousewheel scrolls the table, the row will be focused instead. (So we don't try to refocus the anchor while the focusedRecycleCallback blurs it)
- If cell contents were focused (tabbable child), and a scroll occurs, the cell will be focused instead.

Also ensure action menu focus state is set once an action menu is opened.
- If an action menu button was focused and a scroll occurs, the cell will be focused instead.
@mollykreis mollykreis mentioned this pull request Jun 21, 2024
1 task
msmithNI added 2 commits June 24, 2024 17:20
…e button could be keyboard navigated to, which was no longer the case)
@msmithNI msmithNI merged commit 5be33e3 into main Jun 25, 2024
13 checks passed
@msmithNI msmithNI deleted the users/masmith/table-keyboard-interaction-2 branch June 25, 2024 18:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Table keyboard interaction
5 participants