search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 637 forks source link

Word navigation hotkeys provide no spoken feedback in terminals #11124

Open Neurrone opened 4 years ago

Neurrone commented 4 years ago

Steps to reproduce:

  1. With WSL 1 installed, type bash to launch it.
  2. type the following: apt-get python
  3. Press ctrl+a to move the cursor to the beginning of the line, ctrl+e to move to the end of the line. Also try typing alt+f and alt+b to move to the next and previous word respectively.

Actual behavior:

NVDA doesn't say anything, making this navigation difficult to use and much less useful

Expected behavior:

NVDA provides spoken feedback.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

Version: alpha-20168,1cf36fbe

Windows version:

Windows 10 1909 (10.0.18363.778])

Name and version of other software in use when reproducing the issue:

WSL 1, Ubuntu

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

If addons are disabled, is your problem still occuring?

N/a

Did you try to run the COM registry fixing tool in NVDA menu / tools?

No

Adriani90 commented 4 years ago

cc: @codeofdusk

Neurrone commented 4 years ago

Forgot to add this happens both with and without UIA in console enabled.

codeofdusk commented 4 years ago

Yes, since NVDA doesn't know to check for caret movement in these cases.

We could possibly bind the Emacs-style (c-a/c-e, m-f/m-b, etc) keys to caret movement scripts in terminals. This could lead to unexpected results in terminal programs where those commands don't move the caret though. It also wouldn't detect any custom caret movement commands configured by users.

Auto select detection (or a similar approach) could also handle this.

Neurrone commented 4 years ago

Updated issue title to reflect that this also happens when using ssh. This isn't a bash specific issue.

Neurrone commented 4 years ago

@codeofdusk how reliable would the auto selection detection approach you mentioned be? I like being able to configure that as well.

codeofdusk commented 4 years ago

Not sure if feasible, just an idea. Cc @leonardder.

Neurrone commented 4 years ago

There's also the vi-style key bindings, I'm not sure how difficult it would be to account for that as well, since those are layered keystrokes. I don't think that is encountered as often though, since the emacs style ones are the default.

LeonarddeR commented 4 years ago

@codeofdusk auto select detection is already available in UIA consoles. Even then, feedback for caret movement is still based on scripts. What would you suggest to use autoselect detection for in this case?

Neurrone commented 4 years ago

I'm not familiar with the UIA specification, but are there events that the terminal can implement which could inform NVDA of word / cursor movement? The new Windows Terminal is also still in beta so maybe this is an opportunity to ask for such events to be implemented if possible.

codeofdusk commented 4 years ago

Yes, these events do exist (this is how auto select detection works). I was thinking we could do something similar to report caret movement but that would require bigger code changes.

Adriani90 commented 4 months ago

@Neurrone, @codeofdusk how is this now with NVDA 2024.3 Beta? Is there any improvement noticeable? Are non UIA terminals actually still commonly used? In NVDA the default value seems to be UIA for consoles in advanced settings.

Neurrone commented 4 months ago

There has been no improvement at all, since there aren't any changes in NVDA that would have affected this since I first reported the issue.