What to speak when whole text selection is cancelled

[burmancomp]

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

I would not say it is actually problem but maybe minor productivity point.

Consider that you select some text for example to copy to clipboard. Then you after pressing control+c, cancel selection/deselect text for example by pressing down arrow.

Currently nvda speaks newline content and after it de/unselected text, and finally it says "unselected".

Describe the solution you'd like

When selection is cancelled (whole selected text de/unselected is it necessary to speak unselected text when de/unselection is done via "no selection" keys/key combinations. Text is selected and unselected with shift+cursor movement keys/key combinations like shift+arrow keys shift+home/end, or with control+a. Selection is then changed with those same same shift+keys/keycombinations. In these cases it is reasonable to say what is unselected but is it needed when key/key combination is something which cancels whole selection like arrow keys or home/end.

If unselected text should also be spoken in these cases, would it be considered to say "unselected" before unselected text. Benefit would be that user would then clearly know where new text ends and unselected text starts.

Describe alternatives you've considered

Additional context

[Adriani90]

To be clear, this affects ritch edit areas and browse mode especially.
I don't think we should change anything here, NVDA behaves correctly, especially when you forgot what you exactly have selected before, it is ok to report the unselected text even if you unselect it with other keys than shift+arrow keys. In general when you select something you have a clue about the document and you know somehow which part of the text is reported. Reporting "unselected" before the text being unselected would colide with the reporting of the currently focused text which you land on when pressing a key gesture removing the selection, so the user would get confused why the currently focused text is being unselected while it was never selected before.
Logically when speaking, you also say "hello not selected" and not "not selected hello".

I agree the current behavior might be sometimes confusing, but the other way round would be even more confusing because there is a hearing patern already accepted by most screen reader users.
Narator reports as well the text being unselected first and then the word "unselected".

In NVDA the higher priority is to report the focused text first, and then the unselected text, which is desirable in my opinion.

[Adriani90]

A better approuch to the current behavior though would be to either

1. Make a longer pause between reporting of focused new text after removing selection and the reporting of the text being unselected or
2. Report the unselected text with another voice pitch or so (using refactored speech framework in New speech framework including callbacks, beeps, sounds, profile switches and prioritized queuing #7599.

[burmancomp]

Users have different preferences. A couple of points:

• how important is to hear unselected text if user has decided to unselect it? Would it not be enough to report that what was before selected, is not selected anymore
• does sighted user when unselecting text, read whole unselected text again when he/she has unselected it? My guess is no. If he/she does not read it again why screenreader user should listen it again (at least there should be easy and clear way avoid relistening)
• could setting like "speak cancelled selection" be suitable for all with default value yes?

[Adriani90]

Hearing just the word unselected would give the impression that the text focused is unselected which is not true. Sighted people see the visual selection indicator go away, and they even see the region which is being unselected. So your approach would mean a degradation from the current behavior.
Can you please explain in more detail why you have a problem with the current behavior?

[burmancomp]

For me when I cancel selection, speaking unselected text is mostly redundant information. It would be enough to hear that selection cancelled (or something similar). Situation is different if I use some "selection keys/key combinations" to modify selection.

Mostly I am interested in focused text after cancellation of selection. If I cancelled selection accidentally, I have to reselect unselected text, and I feel that it does not help so much if I heard what selection I cancelled. In addition, we might suppose that most of times my purpose was to cancel selection so in most cases I accept risk.

There are different opinions, preferences, and pros and cons. For me it would be enough to hear that selection is cancelled, and you think that current approach is good. No problem, question is, can we both get what we prefer? I think we can if there would be setting for this. As said, default would be current behavior but there could be also alternatives. One could be sound to indicate cancellation of selection, and onother some suitable phrase to speak to indicate that same, and third alternative could be say "n characters unselected" as it does when there are a lot of selected text. And if then either or both of us change his opinion about suitable approach, nothing but to change setting.

Can you see some disadvantages?

[gerald-hartig]

Converted to discussion

[CyrilleB79]

Hello

First of all, @gerald-hartig why did you convert it to discussion? Do you feel that the problem described here is not enough well defined? I'll try to explain more clearly what @burmancomp is trying to say, adding my own opinion and clarifications.

Preliminary clarifications

First of all, let's clarify some points in the previous discussion:

1. @burmancomp and @Adriani90 speak about focus change, but there isn't actually any problem with selection reporting when the focus change. The issue being discussed here is rather about when the caret position changes or when caret move/selection commands are used.

2. @Adriani90 wrote:

   To be clear, this affects ritch edit areas and browse mode especially.

   On my end, it affects any edit field, e.g. Windows 10 Notepad.

Examples of the issue

Here are two examples of this issue

Example 1

Test done with OneCore Microsoft David:

• In Notepad, write the following line:
  two, three, four one
• Press home to put the caret at the beginning of the line
• With shift+rightArrow, select "two, three, four" (without space at the end)
• Press control+rightArrow
  You can hear "one, two, three, four unselected"

Quite confusing, no?

Example 2

See #11775 for another example when reporting "unselected" on any command may be misleading.

Different use cases

In my opinion, we need to consider three separate use cases (at least):

1. The user uses selection commands, e.g. shift+arrows, control+shift+arrows, control+A, etc. The goal of these commands is to perform a selection or to modify its range.
2. The user uses other caret commands, e.g. arrows, pageUp/Down, control+arrows to move the caret. The goal of these commands is to move the caret at another position. The side effect of these commands is that the previously selected text is just unselected.
3. The users uses commands that are meant to delete some text, e.g. delete key, backspace key, combination of those keys with control, etc.
4. The user uses commands that produces new text, e.g. letters or digit keys to write text. These commands deletes the selected text as a side effect, i.e. the produced text replace the selection).

Solution proposals

Use case 1

For use case 1, NVDA should provide a speech feedback of the effect of the command. The user is trying to adjust a selection range, so they need to know exactly what is selected. Indicating what has been added/removed to the selection range is much more efficient than re-reading the whole selection each time. That's exactly what NVDA reports today. So NVDA reports what is expected and should not be modified in this case IMO.

I think that we all agree on this, but if you disagree, please explain why.

Use case 2

For use case 2, the unselection is a side effect of the command. The user do not want to do anymore action on the selection. The most important information here is to know exactly where the cursor has landed (e.g. read character, word or line), no matter if some text was selected before or not.

There are two possibilities here:

• Using these commands, the user already knows that the previous selection will be unselected. So NVDA could just avoid to mention anything regarding unselection; it will just report the new position (e.g. read character when using left/rightArrows).
• Or, if we want to make something more consistent with the next use case and ensure that any deselection is reported, report "Selection cancelled" after NVDA has reported information on the new position. E.g. when pressing left/rightArrow, NVDA will report the caracter at the new caret's position and then "Selection cancelled"

My personal preference goes for the first option, but I can understand that a beginner who does not exactly know the effects of standard windows caret move commands may appreciate the confirmation that the selection has been cancelled. In any case, I think that there is no need at all to have reported the content (text) of the selection that has just been cancelled.

Use case 3

In this case, the goal of the command is to remove some text. What is reported today depends on:

• the direction of the removal (backwards with backspace or forward with delete)
• whether there was text selected or not when the command is called
• whether control key is used in combination with the other key

The combinations of these 3 parameters do not produce really consistent outputs between one and another. There's probably a matter of long time habits, including other screen readers behaviours.

Use case 4

In this case, the selection removal is just a side effect so we may just report typing as usual if we want only to report the action performed. Though, since text removal is an important side effect, it's probably better to report also "selection removed" as done today by NVDA.

Comparison with narrator

• For use case 1: Narrator does as NVDA
• For use case 2, Narrator does not report "unselected" at all; it just report the text (character, word or line) where the cursor lands.
• For use case 3, when text is selected and delete or backspace is pressed in combination or not with control, NVDA just reports "Selection removed". I'd say that NVDA should do the same thing.
• For use case 4, Narrator just report the typed text; it does not report selection removal at all.

More context

I also want to mention that @mltony has implemented unselection muting in its Tony's enhancements add-on. The fact that this feature has been implemented in a popular add-on is also an evidence that there is a real need to change something, at least for some of us (if not all).

@mltony feel free to give more details, if you have had feedback or requests regarding this features.

Conclusion

@gerald-hartig I hope I have made the picture more precise. Would you accept to re-open the issue, or that I open a new one with this description? The goal would be to fix at least use case 2, and if accepted, also use case 3 as Narrator does.

[seanbudd]

Hey @CyrilleB79,

My understanding is this was converted to a discussion as the UX wasn't clear and we needed more feedback to come to a more precise issue.
I think the information you have provided here (thanks to @burmancomp and others too) is sufficient to open a new issue.

My thoughts on the description itself:

With use case 2: I think an "unselected" announcement is better by default, even if we dont announce the specific text.

For use case 3, when text is selected and delete or backspace is pressed in combination or not with control, NVDA just reports "Selection removed". I'd say that NVDA should do the same thing.

Do you mean narrator reports "selection removed"?

[burmancomp]

Thank you @CyrilleB79 for your comprehensive write-up. In addition, depending on braille settings it is possible to detect cancellation of selection.

[mltony]

Yes I have a fix for that in Tony's enhancements add-on.
+1 that this is a bug and this behavior is pretty annoying.
I proposed to fix this in #11775 a year ago but got no response from NVAccess. I still think this should be fixed, although not sure when I'll have time to prepare a PR.

[burmancomp]

@gerald-hartig could you kindly reopen the issue?