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

Modify NVDA’s speech feedback for copying actions on triple-pressing of certain commands in English to place ‘copied’ at the beginning #6757

bhavyashah opened this issue Jan 18, 2017 · 6 comments · Fixed by #9843


Copy link

bhavyashah commented Jan 18, 2017

Using NVDA’s title reporting or currently focused object reporting key command’s triple press actions for example, I sometimes press them multiple times in order to get them reported enough times for me to completely grasp or memorize. Often, my key presses are so successive that NVDA mistakes me for a triple-press and copies the window title or focused object to the clipboard. Usually, the problem isn’t so much about things getting unintentionally copied, but more so about being unaware of the same. This is because in both the cases of the triple press of the title and object reporting commands among others that I am not currently listing, the entire title or object is reported following which NVDA says ‘copied to clipboard’.
Thus, I propose changing this speech feedback of NVDA from ‘{title}/{object} copied to clipboard’ to ‘copied {title}/{object} to clipboard’, so that a user is aware earlier about the accidental clipboard contents change or the copying action that has inadvertently taken place. Often, I do not listen to the end of particularly long window titles in haste and issue another command interrupting speech at the end. This may be very low priority, but equally trivial to resolve. I must admit though that I am unclear about the impliciations of this string change for other languages, if any.


Make it clearer that text has been copied.

While trying to use commands such as title reporting, sometimes the command is mistakenly pressed 3 times resulting in the title being copied to the clipboard unintentionally. This may happen because the title is long or hard to understand, and the user wishes to hear it repeatedly.

Expected behaviour:

Copied {title} to clipboard

Actual behaviour

{title} copied to clipboard

The proposed change makes it clearer from the start of the utterance that the clipboard has been updated.


This may not translate well into other languages.

Copy link

ehollig commented Sep 12, 2017

Hmmm, thoughts @Qchristensen?

Copy link

Rather than try to increase the clarity that a mistake has been made, another approach to this might be to make it easier to avoid the 3 press mistake in the first place. It seems to me, the user wants a way to re-trigger the last command, and only the last command.

Copy link

I up-vote this change request.
The current message buries the two crucial pieces of information at the end of a possibly lengthy message:

  • The triple press succeeded in a way different than single press
  • The content of the clipboard has been altered

There are three scripts emitting the incriminated message:

  • GlobalCommands.script_navigatorObject_current
  • GlobalCommands.script_reportStatusLine
  • GlobalCommands.script_title

Two additional scripts deal with the clipboard with a different message:

  • GlobalCommandsscript_review_copy: "Review selection copied to clipboard"
  • CursorManager.script_copyToClipboard: "Copied to clipboard"

I guess we should try to adopt a uniform phrasing for the five of them.


  • "Copied {text} to clipboard" as originally requested, not my favorite
  • "Copied to clipboard: {text}"
  • "{what} copied to clipboard" with what being "Navigator Object" / "Title" / "Status bar" / "Review selection" / "Selection"
  • "Copied to clipboard", period, which at least requires no translation effort at all as it is already used

I do not have a personal preference among the last three.

Copy link

XLTechie commented Jun 27, 2019 via email

Copy link

@JulienCochuyt what you are proposing is quite similar to #9028 where the consistency of "{what} selected" was improved. I agree that makes sense to be consistent for all of these types of messages.

I think there are some contradictory requirements to consider:

  • After pressing a command, I don't want to wait for a long title or other text to know if I got the right command.
    • Example problem: "Long application title here copied"
    • The user only knows it was copied (and not selected or some other action) at the end, frustrating for a user uncertain if they have the pressed the right key.
    • Preference for this user: "Copied: Long application title here"
  • After pressing a command, I want to know as soon as possible that I operated on the right text.
    • Example problem: "Copied: Long application title here"
    • The user is unsure they are copying the right text, and have to wait for copied to be said.
    • Preference for this user: "Long application title copied here"

For now I agree, make the messages consistent. Longer term, this falls into a speech messaging UX configuration project.

Copy link

JulienCochuyt commented Jun 28, 2019

@feerrenrut, thanks for pointing this out.

So, I guess the phrasings "Copied to clipboard: {text}" or "{what} copied to clipboard: {text}" would fit most expectations:

  • Instant confirmation of the nature of the operation
  • Quite quick confirmation of the text operated upon, as long as {what} is either omitted or short and translations do not get too verbose
  • Lengthy outputs can be cut without loss of information
  • Uniform among the five copy operations

"Review selection" is the one that can get a bit verbose in French by example.
Probably would "Selection" be sufficient as {what} for both NVDA+F10*2 and control+C.

While testing the change, I realize that including the {what} will probably no suit the needs of the second group mentioned by @feerrenrut, as we are already loosing a bit of their "as soon as possible" with this change.
Also, I noted that among the five operation, four are reported in speech&braille while one, the navigator object, is only announced by speech. For consistency, I suggest to also report it in braille.

JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Jun 28, 2019
JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Jul 15, 2019
JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Aug 13, 2019
JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Jul 2, 2020
feerrenrut added a commit that referenced this issue Nov 17, 2020
Fixes #6757

Co-authored-by: Reef Turner <>
@nvaccessAuto nvaccessAuto added this to the 2020.4 milestone Nov 17, 2020
JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Nov 22, 2020
JulienCochuyt added a commit to accessolutions/nvda that referenced this issue Nov 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging a pull request may close this issue.

6 participants