Request to assign a default gesture for vertical navigation in browse mode
Opened this issue · 14 comments
Is your feature request related to a problem? Please describe.
The vertical navigation feature was requested by #15999 and quickly implemented by @mltony. Since this feature was merged, I've found that it has far more uses than I initially thought.
- Quickly navigate between issues on the GitHub Issue page.
- YouTube Music’s search results and playlist pages originally used button navigation, but there are many elements with the role of a button. When I just want to find the play button, vertical navigation comes in handy.
- In the comment section of YouTube video pages, when I want to focus only on the commentator and their posted content, I previously needed to press the letter H and then press the down arrow twice. With vertical navigation, I only need to use vertical navigation, freeing up my other hand and reducing the number of key presses.
- On more social media or news platforms in China (such as WeChat, Weibo), good accessibility is often not achieved, but vertical navigation provides an excellent solution to quickly find useful information.
- More than 95% of my daily work is done in the browser, and vertical navigation improves efficiency.
Describe the solution you'd like
Based on the above, I think it is necessary to assign a default gesture to vertical navigation to improve the discoverability of this feature and allow more ordinary users to benefit from it.
For example, we assign it to the letter Z or, the left square bracket([).
cc @mltony
Describe alternatives you've considered
None
Additional context
None
Since this is a directional navigation patern, I for myself assigned nvda+alt+up and down arrow key. This feels more consistent and has similarities with row by row navigation in tables.
I completely agree with what @mltony mentioned in the original description, this is one dimensional navigation, just like other quick nav commands, assigning it a single letter key is enough.
For more discussion and clarification, please refer to #15999, I really don’t want to repeat what Tony has explained to you many times here, thank you.
@cary-rowen you have your opinion and that's ok. Indeed vertical nav is a part of indent navigation, and you might better refer to #16467. I see indeed vertical nav as a beginning for indentation navigation patern. INdeed it would really help if @mltony added also left and right navigation, and diagonal navigation as explained in #16467, but it seems he was not willing to do so.
cc: @seanbudd, @gerald-hartig
I don't really understand why you are so harsh sometimes. Where does your frustration come from?
Actually we stand both for the same thing, we would like users to gain more accessibility and use a software that is intuitive. So it would be better if you would exchange some more constructive arguments and look more exactly what followed after that discussion instead of considering only the half truth.
If you have other ideas, please open a separate Issue or discussion, and I may participate if necessary.
In fact, you have already done this, and your above point is far more appropriate in #16467 than here.
If you want to gain approval from others, the first thing to do is to place your opinion in the right place.
As far as this Issue is concerned, I think its goal is very clear. We really don’t need (at least here) to continue arguing about what vertical navigation is. Personally, I agree with Tony’s point of view.
If you want me to say more, it's just repeating what Tony once told you, and I don't know why you're so obsessed with that. This doesn't mean much to me.
Our conversation has caused confusion for those who will read this issue later, and I would like to collapse it if possible.
Thanks
I agree with @cary-rowen - All QuickNav gestures have up and down conotation. That's why in order to make it consistent the gesture should be similar to other QuickNav. I haven't found any use of lesser/greater horizontal offset commands, so indeed vertical navigation is 1-dimensional.
I think @Adriani90 is still not convinced - but at this point it comes down to personal preference. And as I don't have desire to implement 2 dimensional navigation commands - precisely because I myself found them pretty useless in BrowserNav - vertical navigation will stay 1dimensional. Unless anyone else wants to try implementing, but in that case they would also need to prove that the second dimension is useful in some sense.
Ok I will not start again the discussion on use cases of greater / lesser indent navigation because I did it well enough in #16467 and it seems @mltony really doesn‘t want to understand it or is very convinced of his own experiences without considering what many users say and report in such discussions. It is really a pitty that such well skilled developers are so hard to convince of new use cases of different users.
@Adriani90,
These are not new use cases. I mentioned before that I tried all of that previously in BrowserNav and the second dimension in browse mode just doesn't work. There are way too many false positives for it to be useful. That mostly applies to your idea of navigating threaded conversations. Structured navigation in math formulas also doesn't work becuase formulas are a different beast. Talking about your other ideas in #16467:
- Malformed tables in browse mode: vertical navigation is good enough. If you need to switch between columns, you can use paragraph navigation, horizontal navigation doesn't add any new functionality.
- concept boards: not quite sure what's that, but I imagine you're talking about a 2d canvas where sighted people can drop text elements. That one is still tricky to do because there might be multiple elements that have for example lesser x and lesser y coordinate, so disambiguation must be resolved somehow. That's currently not handled in BrowserNa and I would assume it'll need to be handled in some special way.
- Tree-like comments - as I jmentioned this was my primary use case in mind and due to web layout it causes too many false positives to be useful.
- Statistical content with trees and diagrams - diagrams are not really supported in NVDA.
- Structured notes with nested lists etc. - vertical navigation is enough to navigate nested lists.
the second dimension in browse mode just doesn't work. There are way too many false positives for it to be useful. That mostly applies to your idea of navigating threaded conversations.
That might be due to technical limitations which could be made transparent and where people could explore new technical approaches. It seems this discussion is totally missing, because you are convinced that your browse nav add-on approach doesn't work. But this doesn't mean that browser nav is the only technical way to solve those limitations.
navigation in math formulas also doesn't work becuase formulas are a different beast.
I disagree with this, I am using an old version of NVDA with browser nav and when opening pdf documents with mathematical fractions and square roots in the browser, I can easily navigate the fractions and the mathematical formulas, at least much easier than just using vertical nav.
Malformed tables in browse mode: vertical navigation is good enough. If you need to switch between columns, you can use paragraph navigation, horizontal navigation doesn't add any new functionality.
That's not true. Using horizontal navigation makes NVDA read the whole cell which is very helpful when navigating through the columns.
Using paragraph navigation is not helpful in this case, because you don't know how much content is in which cell, when the table is malformated / inaccessible, especially when the text in a cell contains more than one paragraph. Using text paragraph nav is not useful here, because content in columns might be only interactive links / elements and not plain text, so text paragraph nav would skip those.
concept boards: not quite sure what's that, but I imagine you're talking about a 2d canvas where sighted people can drop text elements. That one is still tricky to do because there might be multiple elements that have for example lesser x and lesser y coordinate, so disambiguation must be resolved somehow. That's currently not handled in BrowserNa and I would assume it'll need to be handled in some special way.
This can be explored technically, I am sure there might be a solution for this if people spend some time to think about it. It doesn't have to be the browse nav add-on that is implemented into NVDA one by one.
Concept boards are things like canvas, Miro, and other boards where people can place content in cards. It is not just about drawing things, you can also structure tables on concept boards, but they are not accessible via table navigation commands.
Tree-like comments - as I jmentioned this was my primary use case in mind and due to web layout it causes too many false positives to be useful.
This might be due to bad web authoring, I am sure there are websites where the comment trees are well structured visually and the indentation nav would work properly. But you need to open up and expose this feature to a wider part of the community to find it out. I use for example browser nav and indent nav at work to explore our internal SAP based management information system which contains tree structures for information, and I can easily navigate those with indent navigation. Vertical navigation is definitely not enough in this regard. And still I think even the false positives you are talking about can be technically explored to see how the potential is. But it seems skilled developers like you don't really want to open up the technical discussion on this topic at all.
Statistical content with trees and diagrams - diagrams are not really supported in NVDA.
This is because, amongst others, indent navigation is not available. PDF with statistical content are much more accessible when using browser nav. But yeah, users who really work with statistics every day can tell you whether it works or not. Sometimes it is also good to build some trust on users, instead of taking into account just your own experiences.
Structured notes with nested lists etc. - vertical navigation is enough to navigate nested lists.
Not when you have nested definition lists, or very long lists with different levels. Just the vertical navigation is a big limitation in this regard.
To be clear, I have corrected the part of my comment above which was related to inaccessible tables. Horizontal / diagonal indent nav reads the whole cell, not the whole column, but still the conclusion remains that it is much more useful than exploring such tables with paragraph navigation.
Currently we don't plan on accepting a default key, however more feedback from the community on this is welcome, so this issue is left open.
It is important to consider the trade-off between utility and limited keyboard space
@mltony wrote:
All QuickNav gestures have up and down conotation. That's why in order to make it consistent the gesture should be similar to other QuickNav.
That's not really true. The reason of assigning the gestures by default as they are now, was not the directional conotation, but the name of them which should make users remember them as fast as possible. h for heading, t for table, v for visited link, e for edit field etc. In any of the default assigned quick nav keys the letter is part of the element to which you navigate.
Vertical navigation is an exception, because we don't navigate to a element which is semantically defined within the HTML code, but we navigate by visual structure which is given by coordinates.
There is no letter which is still free and part of the words "vertical navigation". So the most intuitive way is to assign keys which make clear what the feature does: it moves on the screen up and down. And this is best suited in nvda+alt+up and down arrow in my view.
I haven't found any use of lesser/greater horizontal offset commands, so indeed vertical navigation is 1-dimensional.
It is currently 1-dimensional because the feature is not complete. You implemented just a quarter of indent navigation, but the complete logical navigation patern is definitely not 1-dimensional.