Feature request: add QuickNav command for Vertical navigation in browse mode

[mltony]

I propose to add Vertical navigation QuickNav command to NVDA. I I will implement this feature request myself if green light is given by NVDA team.

• We define vertical navigation to be jumping to next or previous paragraph, which is vertically aligned visually with the current paragraph, that is their x coordinate is exactly the same.
• This can be useful on websites that visually display data as a table, but for whatever reason NVDA doesn't see the table. This command can be used to navigate to next/previous cell in the same column.
• A good example of this is issues list on github - with this feature users will be able to find the first issue and then navigate between issues in the list using vertical navigation with a single keystroke.
• I propose to assign by default Left bracket [ and Shift+[ gestures to this command.
• This feature has already been implemented in BrowserNav add-on and by default assigned to NVDA+Control+Up/Down gestures.

[mltony]

Previous discussion in #15996.

[Adriani90]

Since you had already nvda+control+up and down arrow for this, I think a similar command should be implemented in the core as well. NVDA+control+up and down arrow is already assigned to the settings ring in desktop keyboard layout, so I propose nvda+alt+up and down arrow to maintain the logic of vertical navigation in general involving up and down arrow key to which everyone is used to and which is not that different from your addon.

[XLTechie]

I would quite look forward to this feature. @Adriani90's key suggestion seems logical.

[mltony]

@Adriani90,

Porting features from add-on to NVDA core is the perfect time to fix default keyboard bindings if the old ones don't make sense.

I had some reasons to use arrow keys when I initially implemented this about 5 years ago in BrowserNav. I wanted to mimic IndentNav, where using all four arrows makes sense. However practice shows that trying to find parent element NVDA+Alt+Left and child element NVDA+Alt+Right don't make much sense on the web. Therefore it is only up and down.

and Up and Down maps perfectly on general semantics of QuickNav command. It wouldn't make any sense to me that all the QuickNav commands are a single letter and Shift+letter, while vertical navigation should have a different keystroke. I think we should forget about default binding in BrowserNav, as I as the original author declare that in the hindsight the default mapping in BrowserNav wasn't very clever. You would need to provide more convincing arguments then not touching the defaults from the add-on.

[Adriani90]

Actually to me vertical navigation is not really a quick nav per se, it is rather a structural navigation and is more comparable to table navigation which uses also arrow keys to reach next cells, and even uses home and end keys to navigate vertically to the beginning or end of a column. If we follow your argument, then ctrl+alt+home, +end, +page up or down should also get a letter instead because they are also quick navs but this is not logical.Von meinem iPhone gesendetAm 03.01.2024 um 08:15 schrieb mltony ***@***.***>: @Adriani90, Porting features from add-on to NVDA core is the perfect time to fix default keyboard bindings if the old ones don't make sense. I had some reasons to use arrow keys when I initially implemented this about 5 years ago in BrowserNav. I wanted to mimic IndentNav, where using all four arrows makes sense. However practice shows that trying to find parent element NVDA+Alt+Left and child element NVDA+Alt+Right don't make much sense on the web. Therefore it is only up and down. and Up and Down maps perfectly on general semantics of QuickNav command. It wouldn't make any sense to me that all the QuickNav commands are a single letter and Shift+letter, while vertical navigation should have a different keystroke. I think we should forget about default binding in BrowserNav, as I as the original author declare that in the hindsight the default mapping in BrowserNav wasn't very clever. You would need to provide more convincing arguments then not touching the defaults from the add-on. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adriani90]

I propose to implement this feature more broadly, not only for browsers, but to work in browse mode in general, and in other editors with a system caret as well like indentnav, does. Then you could add a message to nvda+alt+left and right arrow saying "indent level navigation not supported" which should apply only for applications where this does not make sense (i.e. web or table calculation applications) or where technically not possible.
The same message should be reported for nvda+alt+up and down arrow when this is not technically possible or it does not make sense.

[mltony]

Actually to me vertical navigation is not really a quick nav per se, it is rather a structural navigation and is more comparable to table navigation which uses also arrow keys to reach next cells

Define structural navigation. The concept of QuickNav only means that there is a forward command bound to single letter keystroke and corresponding Shift+Letter command to go back. So all QuickNav commands are for 1-dimensional navigation. Table navigation is 2-dimensional by definition, that's why it requires arrows and that';s why your argument doesn't make sense to me. Vertical navigation is also 1-dimensional - as I mentioned before I tried 2-dimensional approach in BrowserNav and I found it to be not useful at all. Hence Vertical navigation is 1-dimensional and semantically more similar to all other 1-dimensional QuickNav commands.

I propose to implement this feature more broadly, not only for browsers, but to work in browse mode

The title of this feature request suggest to add this to browse mode, not restricted to browsers.

Re similarity with IndentNav

There is only superficial similarity. And I have years of my own experience with BrowserNav and IndentNav to back it up. I repeat again that assigning arrows to vertical navigation in BrowserNav was a mistake in the hindsight, just because vertical navigation is 1-dimensional, there is no usable concept of second dimension, as I tried to come up with one and failed. I feel writing add-ons is a more exploratory process that I went through, and I do make mistakes. And this is one of them. And I want to learn from this mistake and assign a more appropriate shortcut to vertical navigation, and I am puzzled that you don't agree with these arguments.
And besides, talking about other lessons learned, using arrow keys in IndentNav has its own problems too. It is actually not enough for IndentNav to have only 4 arrows - I wish I had 6: Up,Down, UpLeft, UpRight, DownLeft, DownRight. So if that day comes when I propose to include IndentNav in the core, chances are I will try to pick better keystrokes for it as well.
So to summarize, let's not cling to legacy key bindings that were poor choices on my side years ago; let's just admit that vertical navigation is 1-dimensional and therefore most naturally it resembles other 1-dimensional quickNav commands. It would be a pity to waste arrows on a 1-dimensional command where in fact in the future we can leave it for some other idea that really requires 2-dimensional navigation.

Re: IndentNav

Sure I can propose to include IndentNav in NVDA core, but my time is limited so I am trying to pick highest impact ideas to contribute. IndentNav is only useful to developers, who are a minority, and besides IndentNav doesn't work in VSCode due to #15995, which is another big concern.

[Adriani90]

@mltony It is not that I don't agree with your proposal, it is just that I try to exchange argument with you so we are on the same page at the end and when users come up with questions later we can respond in a more competent way why a certain behavior has been chosen.
Indeed I agree with a lot of points you describe and I think your experience is huge and very valuable.
I think you are right we should implement this in browse mode first, and as an 1 dimensional approach first, and assign a letter to it.
I hope we can agree that the ideal would be to have this approach implemented broader as a structural navigation approach, which means that it follows a clear navigation patern that can be described visually in a structured way and has a multi directional behavior. I really aknowledge you invested a lot of work in indent nav and I still think your approach has huge potential in changing the way people navigate the screen in editing areas.

[seanbudd]

Given the somewhat limited utility of this feature, it should perhaps remain an unassigned gesture, at least to begin with,