Table navigation doesn't respect colspan

[LeonarddeR]

Steps to reproduce:

1. Download colspan.html.txt and remove the .txt extension
2. Open this in a browser (Firefox, Chrome, IE and Edge tested)
3. Go to the table. It has two rows, the lower left cell spanning two columns (b1 and b2)
4. Go to cell b1 (row 1 column 2), press control+alt+down arrow. You will land on the a2 and b2 cell
5. Press ctrl+alt+up arrow

Expected behavior:

NVDA returns to row 1 column 2. Expectation based on Excel behavior

Actual behavior:

NVDA lands on row 1 column 1, so it doesn't get back to the original position

System configuration:

NVDA version: next-14106,059e7f02
NVDA Installed
Windows version: Windows 10 Version 1703 (OS Build 15063.296)

[jcsteh]

Totally agree that this is the ideal behaviour. The question is how to implement this and how to handle the edge cases.

Table navigation uses the cursor position as the point of origin when navigating. This is necessary because otherwise, if you navigated elsewhere in the table (or even to another table) by some other means (e.g. the cursor keys, quick navigation or search), the user expects to navigate from that new position, not the cell at which they last used table navigation. This creates a problem, though, because as far as the cursor is concerned, the position of the spanned cell is exactly the same regardless of how you get there.

To fix this, table navigation needs to keep some additional state, but only act on it if the user hasn't moved the cursor to another table/cell by some other means. Here's where the edge cases come in. Should we preserve this state if the user moves the cursor by some other means but still stays within the cell? Or should we only preserve the state if the user is only using table navigation commands? I tend to think the latter is acceptable. Examples:

• If the user presses control+alt+down arrow, then right arrow, then control+alt+up arrow, should we preserve the origin column?
• What if the user is in b1, then skips over c1 to a2-b2 by searching? Should control+alt+upArrow move to b1 in that case?

Handling these cases is going to be hard to implement and probably overkill.

I can think of two ways to maintain the state:

1. Cache the last table navigation origin and the direction of movement. If the cursor moves at all other than table navigation, throw it away. When table navigation is used again, if the direction is the reverse of the cached direction, just return the user to the cached origin.
2. Cache the last table navigation origin table, row and column. When table navigation is used again, if the cached table, row and column fall within the cell at the cursor (accounting for span), use those instead of the starting coordinates of the cell at the cursor. I think I prefer this approach.

[LeonarddeR]

I agree that your second approach is probably the most cleanest one. I assume you'd cache those things on the tree interceptor?

May be we should also take the reporting of things into account here. E.g. If we are at the a2 and b2 cell and coordinates reporting is on, should NVDA report that this cell spans both column 1 and column 2? I think it should whenever possible. I know this is a completely different issue though

[Adriani90]

Still reproducible in NVDA 2019.1.1 and different browsers (tested in FF 66.0.3 and Crhome 73).

[CyrilleB79]

Just to indicate that this issue is still reproducible with 2020.3 and that Jaws does not exhibit this issue.