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

[A11y] Incorrect focus order when navigating within inserted table using up/down arrow keys #2740

Open
2 of 5 tasks
vhuseinova-msft opened this issue Jul 3, 2024 · 3 comments

Comments

@vhuseinova-msft
Copy link
Contributor

vhuseinova-msft commented Jul 3, 2024

Describe the bug
When user uses arrow keys for navigation in table, focus order is not correct for:

  • first cell in any column before first one when up arrow key is used
  • last cell in the any column before last one when down arrow key is used

To Reproduce
Steps to reproduce the behavior:

  • first cell in any column before first one when up arrow key is used
  1. Open Demo app
  2. Insert a table at least 3*3
  3. Set cursor to the last cell in the table (N*N position)
  4. Use up key to navigate to the first cell in the current column
  5. Use up key again and observe that focus is in the first cell in the previous column
  • last cell in the any column before last one when down arrow key is used
  1. Open Demo app
  2. Insert a table at least 3*3
  3. Set cursor to cell at (0,0) position
  4. Use down key to navigate to the last cell in the current column
  5. Use down key again and observe that focus is in the last cell in the next column

Expected behavior
when user navigates:

  • down in the last cell in any column, they should exit the table and be navigated to the text area after the table
  • up in the first cell in any column, they should exit the table and be navigated to the text area before the table

Screenshots

Screen.Recording.2024-07-03.at.4.06.07.PM.mov

Device Information

  • OS: [e.g. iOS] MacOS/Windows
  • Browser [e.g. chrome, safari] Edge
  • Version [e.g. 22]

Current requirements done:

  • If the cursor is anywhere in the top row and the Up arrow is pressed, it should go to the line above the table, if there is one. Observed: we only do this for the first cell in the row. It looks like we already have logic in place to position the cursor as close as possible to where it was horizontally on the table. (Handle Up and Down in Table #2767)
  • If the cursor is in the first cell of the table and the Left arrow is pressed, it should go to the end of the line above the table. Observed: the cursor moves to the left of the table. (Handle Up and Down in Table #2767)
  • If the cursor is in the bottom row and the Down arrow is pressed, it should go to the line of text after the table, as close as possible where the cursor was on the table (see first point). Observed: cursor always goes to the beginning of the line.
  • If the cursor is in the text below a table and the Up arrow is pressed, it should go to the cell closest to the cursor position (see first point). Observed: the cursor always goes to the last cell.
  • There might be 1 more use case, when user is on the text above the table and Down arrow key is pressed (it looks like it should go to the correct cell to be consistent with 2 point above)

Tasks

No tasks being tracked yet.
@jvillalobos
Copy link
Contributor

Tested on Outlook. Here's what I think we need to change:

  • If the cursor is anywhere in the top row and the Up arrow is pressed, it should go to the line above the table, if there is one. Observed: we only do this for the first cell in the row. It looks like we already have logic in place to position the cursor as close as possible to where it was horizontally on the table.
  • If the cursor is in the first cell of the table and the Left arrow is pressed, it should go to the end of the line above the table. Observed: the cursor moves to the left of the table.
  • If the cursor is in the bottom row and the Down arrow is pressed, it should go to the line of text after the table, as close as possible where the cursor was on the table (see first point). Observed: cursor always goes to the beginning of the line.
  • If the cursor is in the text below a table and the Up arrow is pressed, it should go to the cell closest to the cursor position (see first point). Observed: the cursor always goes to the last cell.

@BryanValverdeU
Copy link
Contributor

The first two points are resolved in #2767

The last to requirements are still pending, and another behavior observed is also missing. Adding it to the list.

There might be 1 more use case, when user is on the text above the table and Down arrow key is pressed (it looks like it should go to the correct cell to be consistent with 2 point above)

  • If the cursor is anywhere in the top row and the Up arrow is pressed, it should go to the line above the table, if there is one. Observed: we only do this for the first cell in the row. It looks like we already have logic in place to position the cursor as close as possible to where it was horizontally on the table.
  • If the cursor is in the first cell of the table and the Left arrow is pressed, it should go to the end of the line above the table. Observed: the cursor moves to the left of the table.
  • If the cursor is in the bottom row and the Down arrow is pressed, it should go to the line of text after the table, as close as possible where the cursor was on the table (see first point). Observed: cursor always goes to the beginning of the line.
  • If the cursor is in the text below a table and the Up arrow is pressed, it should go to the cell closest to the cursor position (see first point). Observed: the cursor always goes to the last cell.
  • There might be 1 more use case, when user is on the text above the table and Down arrow key is pressed (it looks like it should go to the correct cell to be consistent with 2 point above)

@romanisa
Copy link
Contributor

romanisa commented Sep 9, 2024

Keeping this open if anyone wants to pick up the fix for the remaining items.

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

No branches or pull requests

5 participants