Closed juanca closed 6 years ago
Two bugs:
Some interesting investigations to do (as follow ups):
active
and an alphabetical key is pressed (like Google Sheets)interactive
mode, <tab>
(<shift> + <tab>
) should focus horizontally adjacent cellsinteractive
mode, <enter>
(<shift> + <enter>
) should focus vertically adjacent cellsIt's a little bit of a shame that tabbing through fields won't work (correct me if I'm wrong there), since that's what power-users coming from Excel / spreadsheets will be used to.
Exactly. I am working with a designer to explore different user experiences for power users. For example:
<tab>
could save the cell and move interactive focus to the adjacent cellI think this still follows the spirit of the w3 ARIA spec since a user can get out of "tab hell" by disabling interactive mode and then tabbing out of the grid.
More to come!
Follow up to keyboard accessibility in browse mode
P.S. The PR description started off the same but has been updated with new findings and better perspective.
Motivation
According to the accessibility standards, a composite widget needs to have keyboard navigation. This implies three things:
active
mode), it can toggle betweeninteractive
andactive
modes.Due to high probability of keyboard shortcut conflict between the grid and its grid cells, the grid is in "browse" mode until a grid cell is activated. While the grid cell is inactive, it does not respond to any key presses.
<enter>
/<click>
: renderinteractive
grid cell<esc>
: cancel grid cell changes and renderactive
grid cell<enter>
: accept grid cell changes and renderactive
grid cellThe grid component should support both modes: browse and interactive (wording can be updated later). This PR will only focus on interactive mode.
Technical changes and implications