-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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 table block keyboard navigation #16957
Conversation
1b17951
to
840f48a
Compare
…t unstableOnFocus prop
fc74d6f
to
11d0961
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
Aside from the few comments I left, I have some bigger thoughts on the implementation. I feel like we're reimplementing a lot of what WritingFlow
does. WritingFlow
was never written with tables in mind, so that's why it currently doesn't play very nice with it. I think horizontal arrow keys work well, but vertical arrow keys should move vertically across cells instead of horizontally. To me this seems like an implementation issue with WritingFlow
: the component should always look at the visual order of things, instead of the DOM order. I've done some rewriting before to reflect this in #14462, but only within the isEdge
function, not within the WritingFlow
component. I believe we should consider extending this to the WritingFlow
. I think I already wrote this down somewhere on an issue related to table selection or navigation, but I can't find it now. (Edit: see #14675.)
const columnCount = get( state, [ sectionName, previousRowIndex, 'cells', 'length' ], 0 ); | ||
const hasCellAbove = columnIndex < columnCount; | ||
|
||
return hasCellAbove ? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: I think if ( columnIndex < columnCount ) return
would read better.
@@ -80,6 +80,10 @@ _Type_ | |||
|
|||
Keycode for DOWN key. | |||
|
|||
<a name="END" href="#END">#</a> **END** | |||
|
|||
Keycode for SPACE key. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence seems incorrect, same below.
|
||
// Signal our intention to handle the event by disallowing any | ||
// native or other event handling. Even if the next cell to | ||
// navigate to can't be found, selection should still remain in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
|
||
return getLocationOfCellAbove( tableState, selectedCell ); | ||
} | ||
if ( isDown ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
else if
?
See also #14675. It would also be good to split this into multiple pieces:
|
I just tested this and it's working wonderfully! It's so great to be able to arrow through the cells now. Thanks for this. 🌟
|
Thanks for all the feedback. 😄 @ellatrix It does seem like the I think It could check for particular parent elements ( It'd be pretty amazing if that worked out of the box. I'll do some investigation. edit: re-reading your comments, I see what you mean about 'visual positioning', which would mean looking for a physically positioned element below the current selection. |
Thanks @talldan, that would be great! I strongly believe it all belong in |
Status: This is blocked by #17084, which will move some of the functionality from this PR to a
WritingFlow
.Description
This PR implements improved keyboard navigation within the table block. Previously only tab could be used to navigate cells.
This PR implements the following changes:
Arrow keys are now used to navigate cells along with
HOME
andEND
. TheCmd
/Ctrl
modifiers can be used to go directly to the start/end of a column, row, or the entire table (when used withHOME
andEND
)Tab / Shift+Tab is now used to navigate directly to from an individual cell within the table. A user is able to navigate to a cell using arrow keys, shift tab to the toolbar to make some changes to the table, then tab back to the last selected cell. Previously this was quite hard to achieve as tabbing to the toolbar also changed the selected cell.
The implementation follows the described behaviours here and uses a roving tabIndex:
https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html
The changes here open up the possibilities for other future enhancements to the table block:
colspan
/rowspan
), which will require multi-selection.How has this been tested?
Added e2e and unit tests
Manual testing:
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: