nvaccess
scroll the screen when using ctrl+alt+arrow keys in tables
Is your feature request related to a problem? Please describe.
Take this example: https://www.ag-grid.com/example.php
This table / grid has many columns, and they are scrolled into view on the screen when using focus mode to navigate them from left to right and vice versa. In Chrome, this occurs also when using ctrl+alt+arrow keys in browse mode, though with a certain delay. In Chrome, when the screen is scrolled, NVDA interprets the left edge of the visible table as edge of table, although the table can be further scrolled to one or the other side. However, in Firefox the table navigation in browse mode gets broken when columns are scrolled into view while using ctrl+alt+arrow keys. User impact: NVDA's virtual cursor gets stuck in one column and you cannot navigate the table in browse mode column by column properly.
Steps to reproduce:
- Open https://www.ag-grid.com/example.php
- With NVDA running in browse mode, navigate to the table with t
- Navigate some rows downwards with ctrl+alt+down arrow key
- Navigate some columns with ctrl+alt+right arrow key
- Navigate columns back with ctrl+alt+left arrow key.
Actual:
- In Firefox, NVDA throws an error and does not allow for navigating columns back to the left.
ERROR - scriptHandler.executeScript (17:44:02.365) - MainThread (10708):
error executing script: <bound method DocumentWithTableNavigation.script_nextColumn of <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x00F39C70>> with gesture 'Alt+Strg+Pfeiltaste nach rechts'
Traceback (most recent call last):
File "documentBase.pyc", line 362, in _tableFindNewCell
File "virtualBuffers\gecko_ia2.pyc", line 603, in _getNearestTableCell
File "documentBase.pyc", line 288, in _getNearestTableCell
LookupError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "virtualBuffers\gecko_ia2.pyc", line 581, in _getTableCellAt
File "comtypes\_memberspec.pyc", line 523, in __call__
_ctypes.COMError: (-2147024809, 'Falscher Parameter.', (None, None, None, 0, None))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "documentBase.pyc", line 388, in _tableFindNewCell
File "virtualBuffers\gecko_ia2.pyc", line 593, in _getTableCellAt
LookupError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "scriptHandler.pyc", line 300, in executeScript
File "documentBase.pyc", line 497, in script_nextColumn
File "documentBase.pyc", line 423, in _tableMovementScriptHelper
File "documentBase.pyc", line 390, in _tableFindNewCell
RuntimeError: ('Unable to find current cell.', LookupError())
- In Chrome, NVDA does not announce that the edge of table when it is scrolled into view is actually only the edge of the visible part of the table.
Describe the solution you'd like
In both browsers, when using ctrl+alt+left and right arrow keys in such scrollable grids, NVDA should just scroll the screen to left and right while updating as fast as possible the virtual document, so that the user doesn't actually notice that the table is scrolled to left or right. Edge of table should be announced only on the real edge of the table, not on the part that is scrolled into view.
Describe alternatives you've considered
None
Additional context
None
@seanbudd this not a low vision related issue, Nvda‘s table navigation commands do not work properly at all if the screen is not scrolled accordingly to left and right. Can you please retriage this?
While it is a low vision issue, it's far from only a low vision issue. The label may be misleading in this case, since there isn't a label for no vision issues.
A more subtle instance of this issue may be as follows.
If the screen is not scrolled, the user is reading off-screen content in the table. If the user has to perform a mouse action on that content, it will be off-screen, and the user won't be able to.
For an example, try to perform a multi-line comment on a long file in a GitHub pull request, using only the keyboard.
It can be done with mouse routing in the upper part of the table, but when you try to click on the plus sign of the target line after navigating to it with table nav commands, it has a good chance of being off-screen and thus un-clickable.
To me, this should at least be a P4, as web usability is significantly degraded in either example.
If the screen is not scrolled, the user is reading off-screen content in the table. If the user has to perform a mouse action on that content, it will be off-screen, and the user won't be able to.
That's fair, but I don't think it's accurate to say that NVDA doesn't scroll when navigating tables. Looking at the code, I can see that it does. Furthermore, I can prove it with this test case:
data:text/html,<body onscroll="alert('scrolled');"><table style="width: 200vw;"><tr><th style="width: 100vw;">a</th><th>b</th>
This page pops up an alert saying "scrolled" every time the page scrolls. If you use control+alt+arrows, you'll see this alert. If you use the review cursor, you won't.
So, more investigation is needed for the specific cases that are failing, but the issue is not (in general) that NVDA fails to scroll with table navigation.
Thanks for the info Jamie, I've adjusted the title to express more exactly the problem.
I think this is an authoring problem with the table in question. For example, when you navigate to column 9 (which scrolls there), column 10 gets rendered, but when you navigate to column 10 (scrolling it), a subsequent column doesn't get rendered. Programmatic scrolling is always a little different to visual scrolling because it is fundamentally element based rather than continuous, but the page needs to handle it nevertheless. I don't see how NVDA can do more than it's already doing.
Note that when you first load the table, only columns 1 through 7 are rendered. Table navigation with NVDA causes columns 8, 9 and 10 to be rendered. This further proves that scrolling is indeed happening here.
ok thanks very much, this feels like an invalid issue on NVDA's side then. I am closing.