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

What to speak when whole text selection is cancelled #17252

Open
burmancomp opened this issue Oct 4, 2024 · 5 comments
Open

What to speak when whole text selection is cancelled #17252

burmancomp opened this issue Oct 4, 2024 · 5 comments

Comments

@burmancomp
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Contributor Author

burmancomp commented Oct 4, 2024

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
Copy link
Collaborator

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
Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants