Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion for "Speech interrupt for typed characters" option #3027

Closed
nvaccessAuto opened this issue Feb 26, 2013 · 5 comments
Closed

Suggestion for "Speech interrupt for typed characters" option #3027

nvaccessAuto opened this issue Feb 26, 2013 · 5 comments

Comments

@nvaccessAuto
Copy link

Reported by oaron on 2013-02-26 22:24
It is a good idea, but when I use this option, sometimes NVDA is slower than usual. For example, when I browse on a webpage and jump on the headings with the h key, NVDA doesn't interrupt the speech, but in this case the h key is not a typed character. My same problem happens when I want to find a file in the Windows explorer (or Total commander). I press start letter of the file name more times , but after the second press NVDA doesn't interrupt announcing the first one.
Is it possible to turn on the speech interrupt characters option when I'm in a file explorer, or a web browser, and I'm not editing text?

@LeonarddeR
Copy link
Collaborator

Hmm, interesting Idea. Note that speak typed characters only speaks a typed character for characters that are really typed. May be we could modify the function of speech interrupt in a similar way? CC @jcsteh

@jcsteh
Copy link
Contributor

jcsteh commented Jul 17, 2017

Speech interrupt happens earlier than the code for detecting typed characters, so I don't think that's possible. Also, the characters you type in Explorer lists are detected as typed characters.

I guess we could just make this optional based on the role/states of the focused control. However, I'd like to see use cases/real world scenarios for this. Why do you want this enabled for editable content but disabled for non-editable?

@jcsteh jcsteh added feature and removed task labels Jul 17, 2017
@Adriani90
Copy link
Collaborator

There is also a thread on Discord about this, I think the main use case here is indeed efficiency when navigating by letters in non editable areas where users just don't like to hear the characters everytime when navigating to an element or file.

SaschaCowley pushed a commit that referenced this issue Jan 22, 2025
Fixes #16848,
related #10331, #3027

Summary of the issue:
Currently NVDA can only toggle typing echo (characters and words) on or off globally. Users want more granular control to only have typing feedback in edit controls, while keeping it off in other contexts like listss or non-edit areas.

Description of user facing changes
- Added a new option "Only in edit controls" for both "Speak typed characters" and "Speak typed words" settings in Keyboard Settings
- Instead of checkboxes, these are now combo boxes with three options:
  - Off: No typing echo
  - Only in edit controls: Only echo text typed in edit fields
  - Always: Echo all typed text
- By default, "Speak typed characters" is now set to "Only in edit controls".
- Updated relevant documentation in the user guide

Description of development approach
The implementation:
1. Added a TypingEcho enum in configFlags.py with values:
   - OFF (0)
   - EDIT_CONTROLS (1)
   - ALWAYS (2) 
2. Changed keyboard typing echo configuration from boolean to integer values
3. Updated speech.py, behaviors.py and inputComposition.py to use the new enum
4. Modified settings dialog to use combo box instead of checkbox
5. Updated documentation

Testing strategy:
Tested the following scenarios:
1. Basic functionality:
- Open Notepad (edit control)
  - Set to "Only in edit controls"
  - Type text - should be announced
  - Verify both character and word echo settings
- Explorer file lists(non-edit control)
  - Type text - should not be announced
- Test all three modes (Off, On, Only in edit controls)
2. Different contexts:
- Web browser input fields
- Rich text editors
- Read-only text areas
- Terminal windows

Known issues with pull request:
None identified.
@cary-rowen
Copy link
Contributor

After reading the original reporter's description, I think this can also be closed by #17505. It's the same as my original idea.

@Adriani90
Copy link
Collaborator

Thanks @cary-rowen I confirm this is fixed now that users can decide to restrict announcement of typed characters for edit fields only. Closing.

@github-actions github-actions bot added this to the 2025.1 milestone Jan 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants