see 1005271#c47 for details, see https://hg.mozilla.org/mozilla-central/file/tip/accessible/tests/mochitest/tree/test_table_2.html and https://hg.mozilla.org/mozilla-central/file/tip/accessible/tests/mochitest/tree/test_table_3.html

Taking a guess at P3 - please retriage as necessary.

From bug 1005271 comment 47: > Yes, I think so, since if you resize the window in example 1 to be smaller, the table gets rerendered in a way that NVDA no longer sees it as a table. This prevents the use of its ctrl+alt+ArrowKey table commands to navigate to next cell, previous cell, cell above or cell below. I'd say this was caused by the bug I patched in bug 1460244 comment 6 where the ARIAGrid*Accessible classes were being used instead of ARIAGrid*AccessibleWrap. Marco, this is probably worth re-testing now that this fix has landed.

(In reply to James Teh [:Jamie] from comment #2) > From bug 1005271 comment 47: > > > Yes, I think so, since if you resize the window in example 1 to be smaller, the table gets rerendered in a way that NVDA no longer sees it as a table. This prevents the use of its ctrl+alt+ArrowKey table commands to navigate to next cell, previous cell, cell above or cell below. > > I'd say this was caused by the bug I patched in bug 1460244 comment 6 where > the ARIAGrid*Accessible classes were being used instead of > ARIAGrid*AccessibleWrap. Marco, this is probably worth re-testing now that > this fix has landed. This is still a problem with latest Nightly builds. 1. Bring up that example 1. 2. Press Alt+Space and make sure the window is maximised. 3. Examine the table. Everything works. 4. Now press Alt+Space and choose Restore. 5. Reexamine the table. There are still table semantics spoken, but try using Ctrl+Alt+Arrows. You'll hear error sounds and no table navigation is possible.

Just to make the example easier to find: https://codepen.io/jensgro/pen/dPPEqy Confirmed. In the below, the indexes are all 0 based, since that's what the API deals in. 1. The table reports 3 rows, 1 column. 2. Retrieving the cell at any row/column (even 0, 0) fails with E_INVALIDARG. 3. The cells in the header all report correct coordinate information, even past column 2. 4. The cell in the footer reports row 1 column 0, but not column span. 5. The cells in the body report correct column indexes (even past column 2), but they all report row 0. thead/tfoot/tbody are involved, so I suspect this might be at least impacted (if not fixed) by bug 1461244.