Feature request: add new navigation patern by indentation

[Adriani90]

Is your feature request related to a problem? Please describe.

Summary of #16230 + my thoughts and experience. In lots of situations content on the screen is structured by indentation level. The content is visually readable in a much better way. Unfortunately there are more and more situations where blind people cannot access such structured content efficiently, and thus a lot of information is lost, participation is almost impossible when working together with sighted people. We see this a lot in the german and romanian community, but also confirmed by other users like @mcsedmak, @brunoprietog, @cary-rowen, @TheQuinbox, @akash07k, @jacob-kruger-work, @niranjan-differenzsystem, @towebo, @LitianT80, @pranavlal, and @LittleStar-VIP. Indentation level is defined as the distance of the first visible letter / number / punctuation / symbol character of content from the left edge of the screen, meaning the coordinates on the x axis. The indentation level can be adjusted by

• Tab or space characters in many editors
• html table cells
• CSS or any other design technology specifying the coordinates of the content on the x axis
• Information about object coordinates provided via accessibility APIs. Following content is usually structured by indentation level and such a navigation patern would be very useful:
• Code in IDEs in different programatical languages such as python
• Text columns in digital news letters (e.g. written in MS Word or pdf documents)
• Tables in browse mode documents or in editable areas (also MS Word)
• Table like structures where table navigation is not supported (e.g. Libreoffice)
• CSS display tables counting also as table like structures but without native table navigation support
• Mathematical equations (e.g. polynom divisions or complex postulates where more divisions are displayed in different indentation levels
• Content on browser based concept boards and project management boards (e.g. Miro, Concept board, White board in MS Teams, Asana etc.)
• Websites which display conversations with different comment levels in different indentation levels (e.g. Reddit)
• Statistical content with trees and diagrams
• Structured notes with nested lists etc.
• Checking visual structure of a document when blind people are structuring content in documents and are working together with sighted people.

To overcome the challenges of complex content, people use different workarounds such as converting tables from documents where table navigation is not supported. People convert them to tabular structures, paste them in e.g. notepad++ and use the old indentnav add-on with an outdated NVDA version to navigate and better understand the content structure and participate in different projects. In concept board environments, blind people are often left out of the loop because participation is almost impossible. Meanwhile, mathematical content is accessible to some extent when equations are written in certain programs, but reading mathematical publications in pdf documents or Word documents is still not really doable due to, amongst others, missing indent navigation. In coding contexts, people often also use the outdated indentnav add-on, or they have to do mind gymnastics to understand the content and build connections between blocks or clutters. On Websites, notes and treess with visually well structured content, people with blindness do not really have a clue about the structure because quick navigation keys do not provide any idea of dimensional paterns. So often the communication between blind people and sighted people is disrupted. Telling someone who is blind that there is a button on the top right of the screen doesn't help at all, and on the other hand a blind person cannot explain the design of the content on the screen to a sighted person in dimensional terms.

Describe the solution you'd like

Introduce a new navigation patern by indentation level in following areas:

• Editable areas such as edit fields, and every other document where system carret is used in focus mode to edit
• Browse mode (virtual document) Note:

1. in editable areas (focus mode with system carret), NVDA could use coordinates of the content (letters, numbers, symbols or table cells)provided by the accessibility API to retrieve indentation level (e.g. in Libreoffice or MS Word documents).
2. Where these are not available, fall back on tab and space characters. Tab and space characters can be used to determine the indentation level when using focus mode in edit fields such as multi line edit fields in browsers or IDEs and editors like notepad++, richedit areas etc.
3. In editable areas, when using tab and space characters to determine indentation level, Provide a way to restrict the indent navigation by blocks (very useful e.g. in notepad++ or other IDEs).
4. In browse mode (virtual document), use x axis coordinates either provided by the browser or by any other application which supports browse mode, in order to retrieve indentation level (works also in Adobe reader).

For this navigation patern, following key gestures would be appropriate:

Laptop keyboard layout

Use table navigation command concept to navigate vertically and horizontally with diagonal navigation from top left to lower right or top right to lower left of the screen: • NVDA+alt+windows+up and down arrow: navigate to previous / next line by same indent level vertically up and down (using pg up and pg down instead of up and down arrow keys ignores clutter lines) • NVDA+alt+windows+left and right arrow: navigate to previous / next line by lesser or greater indent level from top left to lower right • NVDA+alt+right and left arrow: navigate to previous / next line by greater or lesser indent level from top right to lower left (does not work when the indent navigation is limited by blocks).

Note: In editable areas, when using tab and space characters to determine indentation level, ad the command nvda+i to turn the indent navigation restriction by blocks on or off (very useful e.g. in notepad++ or other IDEs). When pressing nvda+i, NVDA could report "Limit indent navigation by blocks on" "Limit indent navigation by blocks off"

Desktop keyboard layout

Note: for this to work, the proposal is to use the numpad which provides all desired commands. An easy way would be to toggle between indentation navigation and ASCII/Unicode character modes via Alt+numLock. Once indent navigation is enabled, following commands could be used:

Block limit indent navigation on (supported only in IDEs):

• Alt+numPad2/NumPad8: navigate to next / previous line with same indent level vertically up and down within current block (add the windows key to ignore clutter lines)
• alt+numPad1/numPad3: navigate to next/previous line with lesser/greater indentation level from top left to lower right of the screen within the current block

Block limit indent navigation off (supported in editable areas where a system carret is used, and in browse mode):

• control+numPad2/numPad8: navigate to next / previous line with same indent level vertically up and down (add the windows key to ignore clutter lines)
• control+numPad1/numPad3: navigate to previous/next line with lesser/greater indentation level from top left to lower right of the screen
• control+numPad9/numPad7: navigate to previous/next line with greater/lesser indentation level from top right to lower left of the screen.

This approach would improve significantly the user experience with NVDA when dealing with the problems described above.

Describe alternatives you've considered

None

Additional context

Definition of block provided by @mltony: A block is a bunch of lines with higher indentation level surounded on either or both sides by lines with lower indentation level. e.g. a Python or properly indented C++ function. That means e.g. function declaration line has lower offset than its entire body, so function body would be a single block. Blocks can also be nested.

Definition of clutter provided by @mltony: Clutter means lines composed of characters like "(){}:", so basically lines without letters or numbers.

[Adriani90]

cc: @seanbudd, @gerald-hartig I summarized most important things from that long issue here, hope this helps.

[akash07k]

Amazing description and problem statement

[akash07k]

I agree and vote for this feature request

[burmancomp]

I think showing indentations in braille should be taken into account. When navigating with braille display indendations should be tried to show.

[Adriani90]

At least for indentation level adjusted by tabs and space characters this is already shown on the braille display. For tables and other x axis adjustments I am not sure, at least for tables I think there is a separate issue on Github about indentation not being shown properly on the display.

[CyrilleB79]

cc: @seanbudd, @gerald-hartig I summarized most important things from that long issue here, hope this helps.

Seems that you have not summarized the drawbacks of including indent navigation described in #16230 before closing it. The main ones seems to be the ones in NV Access' last comment in #16230, i.e. https://github.com/nvaccess/nvda/issues/16230#issuecomment-1977768904: "extremely limited audience" of the feature as well as its associated "maintenance cost".

Also when performing a summary, you should probably add the labels that were added by NV Access on the old one if relevant; I'll add them.

At last, and given #16230 is not so old, people involved in the discussion of the "old" issue #16230 would probably appreciate to be CCed in this new summary issue, especially the one more involved. Here it seems that only a subset of them have been named. So to be complete: cc @pawelurbanski, @LeonarddeR, @krperry, @XLTechie, @pranavlal, @lukaszgo1, @Brian1Gaff, @ruifontes

[Adriani90]

@CyrilleB79 this blows up the discussion. The drawback which were addressed in that issue were based on the fact that @mltony formulated his request as being relevant only for developers, which is in fact not the case and this summary does address that. Moreover, many of my comments in that issue have just been ignored. So those drawbacks are not valid anymore and a discussion should be rather focused on this issue description rather than summarizing every comment of that one. Also drawbacks formulated by @LeonarddeR were mittigated by my comments in that old discussion, and as we see from this feature description the request is more globally which is not really suitable for an add-on. Also when you talk about implementation cost, this can be always a drawback and it is not a valid argument in my view. If someone has a better alternative which has less implementation cost, please suggest. But to define implementation cost as the main reason for closing a discussion is not suitable. The community has implemented solutions in NVDA which were more costly than this. NVDA already has the ability to determine indentation levels.

Next time please focus on technical discussions on how to solve the problem or logical arguments if this should not be supported. it is now a different basis as compared to the request description in #16230.

[CyrilleB79]

@Adriani90, according to what I can read in the old issue, and especially the only comment that I have mentioned, people (including NV Access) have agreed that the feature is not useful only for developers but also in many other use cases. But, on the fact that the audience is limited and on the question of the maintenance.cost of this specific feature, there is not yet a consensus including NV Access.

My goal was not to close the discussion but rather to avoid forgetting an important part of it in the summary. And to clarify things, I have no strong opinion on if the feature should be added in the core or not; my last comment (https://github.com/nvaccess/nvda/issues/16467#issuecomment-2095759950) is not aimed to express my personal opinion on the feature but should only be considered part of the triage job.

Re your comments being ignored, I do not know to what you are referring without any more precise reference in this big discussion. But please do not take it personally. People comment when they can and when they have something new to say; else comments (yours or others) may remain unanswered.