You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of Shift+Tab key navigation in the KTable component does not follow the ideal order of navigation, leading to an awkward and unexpected user experience.
Detail:
In #727, @BabyElias introduced a new component KTable. Later, in #804, @shivam-daksh refactored the code for better Readability and Maintainability. However, from the initial implementation, backward navigation using Shift+Tab was not ideal as expected.
Expected Behavior:
When using Shift+Tab to navigate backward, the focus should move through the focusable elements within a cell in reverse DOM order, just like Tab moves forward. This means that pressing Shift+Tab should focus the previous focusable element, respecting the nested order of elements.
Example:
Given a table with the following structure:
Row 1:
Cell 1
Cell 2
Cell 3 containing:
Button 1
Button 2
Row 2:
Cell 1 (current focus)
Cell 2
Cell 3 containing:
Button 1
Button 2
Note:Cell 3 > (Button 1, Button 2) indicates that Cell 3 contains two focusable buttons.
Steps to Reproduce:
Focus on Cell 1 of Row 2.
Press Shift+Tab.
Observe where the focus moves.
Actual Behavior:
Pressing Shift+Tab from Cell 1 of Row 2 moves the focus to Cell 3 of Row 1, instead of Button 2 inside Cell 3 of Row 1. Subsequent presses may not correctly navigate through the internal focusable elements in reverse order.
Video: View actual behavior video
Expected Behavior:
The focus should move to Button 2 inside Cell 3 of Row 1 when Shift+Tab is pressed from Cell 1 of Row 2. Continuing to press Shift+Tab should navigate to Button 1, then to Cell 3, and so on, following the reverse order of the focusable elements.
Video: View expected behavior video
Impact:
This issue affects keyboard navigation, leading to a less intuitive and potentially confusing experience for users who rely on keyboard input. Proper Shift+Tab navigation is essential for accessibility compliance and overall user satisfaction.
Suggested Fix:
Modify the Shift+Tab key handling in the handleTabKey function to ensure that the focus moves to the previous focusable element within the cells, following the correct reverse order.
Add labels
Please choose the appropriate label(s) from our existing label list to ensure that your issue is properly categorized. This will help us to better understand and address your issue!
The text was updated successfully, but these errors were encountered:
Hi @shivam-daksh, thank you! Very nice issue description. I think there may only be a little typo and Cell 4 wasn't intended. But overall I think the expected behavior makes sense to me. @BabyElias tagging you if you'd like to give confirm :)
Summary:
The current implementation of Shift+Tab key navigation in the KTable component does not follow the ideal order of navigation, leading to an awkward and unexpected user experience.
Detail:
In #727, @BabyElias introduced a new component KTable. Later, in #804, @shivam-daksh refactored the code for better Readability and Maintainability. However, from the initial implementation, backward navigation using Shift+Tab was not ideal as expected.
Expected Behavior:
When using Shift+Tab to navigate backward, the focus should move through the focusable elements within a cell in reverse DOM order, just like Tab moves forward. This means that pressing Shift+Tab should focus the previous focusable element, respecting the nested order of elements.
Example:
Given a table with the following structure:
Row 1:
Row 2:
Note:
Cell 3 > (Button 1, Button 2)
indicates that Cell 3 contains two focusable buttons.Steps to Reproduce:
Actual Behavior:
Pressing Shift+Tab from Cell 1 of Row 2 moves the focus to Cell 3 of Row 1, instead of Button 2 inside Cell 3 of Row 1. Subsequent presses may not correctly navigate through the internal focusable elements in reverse order.
Video:
View actual behavior video
Expected Behavior:
The focus should move to Button 2 inside Cell 3 of Row 1 when Shift+Tab is pressed from Cell 1 of Row 2. Continuing to press Shift+Tab should navigate to Button 1, then to Cell 3, and so on, following the reverse order of the focusable elements.
Video:
View expected behavior video
Impact:
This issue affects keyboard navigation, leading to a less intuitive and potentially confusing experience for users who rely on keyboard input. Proper Shift+Tab navigation is essential for accessibility compliance and overall user satisfaction.
Suggested Fix:
Modify the Shift+Tab key handling in the handleTabKey function to ensure that the focus moves to the previous focusable element within the cells, following the correct reverse order.
Add labels
Please choose the appropriate label(s) from our existing label list to ensure that your issue is properly categorized. This will help us to better understand and address your issue!
The text was updated successfully, but these errors were encountered: