Braille: when routing review cursor, route also system caret if desired

[burmancomp]

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

If braille is tethered to review cursor, system caret is not moved in text areas when navigated with braille display buttons (scroll forward/back, next/previous line). This is fine because then system caret keeps it position when checking something for example from previous line.

But if you navigate with display buttons for example to the previous line and there is typo you would like to correct, it is quite complex. You can press routing button to get review cursor to the desired position, but then you have to move system caret with separate command.

Describe the solution you'd like

There should be setting in the braille settings dialog. Setting could be something like "Routing review cursor routes system caret". This setting would have effect only if braille would be tethered to review cursor. Current behavior should be default.

Describe alternatives you've considered

In addition to the setting described above some modification of script_braille_routeTo in globalCommands.py.

Additional context

If accepted, I could try to implement this.

[burmancomp]

This alternative where reviewing content without affecting caret and routing caret to reviewing position when needed has been supported for decades by several software.

NVDA supports it also but it requires more steps: pressing routing button and then moving focus/caret. I think this could be combined and performed with one routing button press.

Setting in braille settings dialog which could be for example "Routing review cursor routes system caret" could be a feature flag which default would be disabled. Because setting would only have effect if also braille would be tethered to review cursor, setting could be hidden when braille is tethered to automatic/focus.

There should not be difference in reliability because adequate implementation could only combine pressing routing button with moving focus/caret (mainly without spoken messages).

This would have no effect on many braille users but some would get additional alternative to use NVDA with their braille displays.

[Jykke67]

Yes. This would be more than useful at least for advanced braille users.

Hopefully this will not just be discussed for ever without implementation.

[irrah68]

I think this would be a very useful feature. This is something I have always been waiting to happen in NVDA. Burmancomp has compiled a test version of NVDA and I have tried it with my Braille display. It seems to work as expected.

[burmancomp]

I noticed there is issue #3166. Could these both be solved at same time, and could same solution be acceptable for both issues?

[Jykke67]

I really do hope, and I’ve said this earlier, that this feature, like the other one discussed, would be implemented to NVDA as soon as possible, or even earlier without an endless discussion about the issue.

The same goes for the verbosity issue that has been discussed concerning different verbosity levels in order to customize announcements of heading levels etc. on webpages.

[burmancomp]

@seanbudd

Why product decision is needed in this case (I'm not familiar with product decision process or practice)? Do you think there are some disadvantages if this is implemented with feature flag setting or do you think other implementation would be better or should there be more people who would like this to be implemented? I suppose many screenreaders have supported this.

Many questions but I would only like to know if this could be implemented to NVDA some day, and what it would require.

[michaelDCurran]

I support implementing a solution for this.
I see 3 options:

1. Provide an extra config option when tethered to review, where if a routing button is pressed, both the review cursor and system caret are moved.
2. When tether is automatic, and review cursor is temporarily shown in braille, pressing a routing button will move both review cursor and system caret.
3. If tether is set to review, or tether is automatic and braille is temporarily showing review cursor, double pressing a routing button moves both review cursor and system caret.

My preference would be option 2.
If this is implemented issue #3166 can be closed.

[burmancomp]

I would see this as follows:

1. feature flag setting which defines if routing review routes also system caret; available/has effect when braille is tethered to review or automatic; default value disabled
2. if "routing review routes also system caret" is enabled and braille is tethered to review (manually or automatically), routing buttons route review cursor and if possible focus/caret.

If that would work only when tethered to automatic, it would require - as it does now - extra step (some "object" command) to start review with braille. It would also introduce behavior which would not be available in manual review mode. But if it would work in addition to manual review mode, also when tethered to automatic, it would give more options for users. In automatic mode extra stpe is required, but if user likes automatic mode and extra step is not problem then he/she gets option to route also system caret when reviewing.

I consider double press of routing button also as extra step if user wants to review with braille and then with routing button get focus/caret moved if possible.

It is also possible to have input gesture which toggless routing review routes also system caret setting so user can easily change behavior.

[LeonarddeR]

As pointed out in #15044, I really want to take this back to the drawing board. It looks like @michaelDCurran expressed his preference for a solution in #14885 (comment) but #15044 chose another implementation. Furthermore #15044 also seems to fiddle with focus. I'm not sure whether that's desirable.

First of all, I think we need to understand the use case of this feature better. Here are three findings that make me question the necessity of changes in this area. Even worse, I'm afraid it will cause unintended side effects.

Finding 1

1. Focus the desktop
2. Set braille tethered to review and review cursor to object
3. Observe that a routing key press on a desktop icon will perform the action on the object, just as what would happen if tethering was set to focus.

Technical explanation: NVDAObjectRegion.routeTo calls doAction on the object.

Finding 2

1. Focus the desktop
2. Set braille tethered to review and review cursor to screen
3. Observe that one routing press on an icon will set the review cursor and a second press will try to perform a single mouse click on that text, which in this case means that you';re about to rename the icon.

Technical explanation: TextInfo.RegionrouteTo sets review cursor on first press and performs textInfo.activate on second press, which performs the mouse click.

Finding 3

1. Open Notepad in Windows 11
2. Set braille tethered to review and review cursor to object
3. Observe that one routing press on a character will set the review cursor and a second press will try to perform a single mouse click on that character, which implicitly moves the system caret.

Technical explanation: TextInfo.RegionrouteTo sets review cursor on first press and performs textInfo.activate on second press, which performs the mouse click on the character.

[burmancomp]

@LeonarddeR I tried what you described in findings. System is Windows 10. I think behavior is very similar but I had "Route review cursor and system caret" disabled. Finding 2 required 3 presses but nothing was selected before first press.

Enabling "Route review cursor and system caret" gives same result with finding 1 and finding 2.

Could you please clarify this?