[cartertemm]

Link to issue number:

Closes #20954

Summary of the issue:

NVDA speaks selected text only if it has fewer than 512 characters. Longer selections are reported as a character count. The limit is hard-coded and not able to be changed by the end user.

Description of user facing changes:

There is a new spin control setting in Voice settings, "Speak selected text if it has fewer characters than", that adjusts the limit. The default is 512. The range is 1 to 10000.

This same limit applies when the read selection command (NVDA+shift+upArrow) is pressed twice or three times to spell the selection.

Description of developer facing changes:

This change deprecates the speech.speech.MAX_LENGTH_FOR_SELECTION_REPORTING constant. Until it is removed (possibly in NVDA 2028.1), it returns the value of config.conf["speech"]["maxSelectionReportingLength"]. Add-ons that read this constant keep working, but a deprecation warning is logged.

Description of development approach:

• Added maxSelectionReportingLength to the [speech] section of the config spec.
• Added speech.speech._isSelectionShortEnoughToSpeak, which both callers now use.
• Added a spin control with context sensitive help to the Voice settings panel.
• Replaced the constant with a RemovedSymbol deprecation through utils._deprecate.handleDeprecations.
• Documented the setting in the User Guide.

No changelog entry has been added due to the feature freeze.
I expect this PR to stay open until planning begins for the next release, or until the feature is ready.

Testing strategy:

Unit tests in tests/unit/test_speech.py check that text under the limit is spoken, that text at the limit is reported as a count, and that the deprecated constant returns the configured value. The full unit test suite, lint, translatable string and license checks pass locally.

I manually tested this on Windows 11 25H2, running from source:

1. Open Voice settings (NVDA+control+v) and confirm the new setting shows 512.
2. Set it to 10 and press OK.
3. In Notepad, select 9 characters. NVDA speaks the text.
4. Select 10 characters. NVDA says "10 characters selected".
5. With 9 characters selected, press NVDA+shift+upArrow twice. NVDA spells the text. With 10 selected, NVDA reports the count.
6. Restore the setting to 512 and confirm long selections behave as before.

All steps behaved as expected.

Known issues with pull request:

None.

Code Review Checklist:

• Documentation:
  • Change log entry (left out due to the feature freeze, see above)
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[CyrilleB79]

Hi @cartertemm.
On which basis did you choose the 10000 char max threshold?
Do you know some synth / text causing NVDA freeze when a too long text is being reported at once? If yes, which one and for which length or text type?

[cartertemm]

Hello @CyrilleB79,

The 10,000 character limit was admittedly somewhat arbitrary, though based on my experience in notepad when I attempt to read a line that is that long or greater, I begin receiving lag of 300MS or so, which increases based on the length of the text.

As for crashes, I know that the eloquence synthesizer is not able to handle large strings at one time without taking NVDA with it, and I recall mixed behavior as described in #13432, #4669, and #8455 where the synthesizer did not appear to matter.

This having been said, 10,000 does sound rather low, so I am not opposed to making the option unbounded in the unlikely event that someone wants to turn off selection announcements at the cost of potential lag.

[CyrilleB79]

This having been said, 10,000 does sound rather low, so I am not opposed to making the option unbounded in the unlikely event that someone wants to turn off selection announcements at the cost of potential lag.

Actually, no. My concern was rather that this limit be even already too high, in case this introduces known issues, lags or even crashes, with some synth. If we introduce a new setting, excepting in the Advanced panel, I'd expect it to be compatible with all most popular / used synths.

Else, I'd prefer this possibility to be available in an add-on; the needed API could though be introduced in core for such add-on if needed, e.g. extension points.

@seanbudd what's NV Access opinion on this?

[CyrilleB79]

Also, regarding the option, I wonder if Speech settings is the most appropriate category? Most of its items just apply when you read text, not when doing something quite specific such as selecting text.

Although I do not find an ideal alternative category. I had thought to:

• Document navigation, since navigation in text and text selection are quite close.
• Keyboard settings, since the option defining what to report when doing a selection is a bit like asking what is reported when typing characters or words...

But none of these 3 possibility is totally suitable for me.

Though, I think it deserves at least be discussed, hence this comment.

[cartertemm]

I have just confirmed that 10,000 character lines do not crash any of the default synthesizers (eSpeak NG, Microsoft SAPI5, or Windows OneCore). There is a slight delay, however this happens when the line is reviewed before it is selected anyway and is not impacted by the change.

For what it's worth, I think this belongs in core. As long as selection announcements are available, users should be given the option to customize when they happen.

[seanbudd]

Nice work @cartertemm - just some minor changes suggested.

[cartertemm]

Appreciate the suggestions, I implemented all of them. Let me know if there is anything else you would like to see here.

[seanbudd]

Thanks @cartertemm

[Qchristensen]

User guide reads well

[CyrilleB79]

@seanbudd, this PR has been merged with a new feature for 2027.1 what is in contradiction with the new "no new feature" rule for .1 releases.

I am the opinion that this rule is quite strict and it may be desirable to make it more flexible. I am discussing this rule in #20627 (comment) and if you want to discuss the rule further, please discuss it there too, not here/

Regarding this PR we have 2 options:

1. Revert it and plan it for 2027.2
2. Keep it

I am quite reluctant to revert it, the rule being too strict in my opinion.

Though if we keep it, the change log should be updated with:

• an item in "New features" section
• An item in "Deprecation" section

Alternatively to the deprecation we may choose to remove completely the symbol as an API-breaking change since we are in 2027.1.