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

incorrect speaking of progress bar updates #4388

Closed
nvaccessAuto opened this issue Aug 14, 2014 · 13 comments
Closed

incorrect speaking of progress bar updates #4388

nvaccessAuto opened this issue Aug 14, 2014 · 13 comments

Comments

@nvaccessAuto
Copy link

nvaccessAuto commented Aug 14, 2014

Reported by blindbhavya on 2014-08-14 16:52

Steps to reproduce

  1. Ensure that you have set progress bar updates reporting status set to beep and speak progress bar updates.
  2. Listen carefully to NVDA giving the progress bar updates of a very short action, i.e. a progress bar that would update itself very quickly.

Actual Result

As the progress is made swiftly the beeps will be played correctly. However, NVDA will not speech interrupt for the speaking of newer progress bar updates. Instead, NVDA will complete each announcement without speech interrupt (i.e. 10% 20% 30% 40% etc.)

Expected Result

Let the beeps be played as they are. But there should be a feature in NVDA that allows the user to decide whether they would like speech interrupt for newer progress bar updates.

Also, do you think that the beeping and speaking is not in coordination?

@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2014-08-15 11:28
Well, its a time thing surely? It will take a long time to say a queue of words, than it will take to beep on a short action, so assuming no new speech is generated you will hear the words going on after the bleeps have anded and the job finished, but of course you can interrupt it by pressing keys.

I don't see how this could be any other way, unless you dynamically change the incrememts in the speech.
To me the main issue with spoken progress bars is the lack of 100 percent most times, but this could just be Windows.
I use beep and speech but I'm prepared to accept the limitations.

@bhavyashah
Copy link

I am still able to consistently reproduce the reported bug. Any thoughts on the assignment of a priority to this ticket (a P3 IMHO if implementation cost is not too high)? @feerrenrut @jcsteh

@feerrenrut
Copy link
Contributor

I'm a little unsure of the behaviour being described here, on my system (Windows 10) when I do the following:

  1. Copy a folder containing enough stuff that it will take about 5 seconds to paste.
  2. Paste into another folder.

Actual:
NVDA reports:

76% complete
Copying 925 items from testFolder to testFolder2 - 76% complete  grouping
Pause the operation  check box  read only  not checked  Pause the operation

@bhavyashah Could you please outline what you expect NVDA to report? Do mean NVDA should interrupt itself as the progress bar changes eg:

Seventy, Eighty, Ninety, Ninety Nine percent complete

@bhavyashah
Copy link

Updates of the progress bar (of Windows during copying of files) you have tested with are not indicated by speech or beeps, which, I suppose is a separate issue (which I must remember to file someday) altogether, as it seems to me. Could you try another progress bar, one which NVDA does recognize and can speak and beep for, in which you will automatically notice that NVDA is saying all percentage intervals from 1% to 100% completely making it lag far behind the beeps which have already indicated 100%. Do I make any more sense now? The example I usually test with, although this bug is certainly applicable to all other progress bars, is the one that appears when I press the Analyse button in CCleaner.

@feerrenrut
Copy link
Contributor

Ok, I think, I see what you mean now. I have made a test application to make it easier to reproduce this problem:
ProgressBarTest.zip

The progress bar can increment faster than NVDA can speak the percentages. NVDA's speech becomes queued and in this case, the progress bar may have been complete for several seconds before NVDA finishes announcing the progress updates.

Instead, you are requesting that each percentage announcement can interrupt the previous one. This may mean that on very fast progress bars, there is a series of hard to decipher noise followed by "90%". EG something similar to:

te twe thir four fife six seven eight 90%

@bhavyashah
Copy link

Precisely. I haven't tested the zipped file you sent but I am very sure from your textual description that you have interpreted the bug correctly.

@jcsteh
Copy link
Contributor

jcsteh commented Aug 7, 2017

I haven't actually tested this, but looking at the code, it's supposed to only speak percentages every 10%. However, without looking deeply, it looks like we might not be updating the cache for updates which don't speak, which could result in more percentages being read than should read.

@jcsteh
Copy link
Contributor

jcsteh commented Aug 7, 2017

Note that this still doesn't interrupt previous percentage utterances, but it would make things a whole lot better if it worked. I'm not sure interrupting is a good idea here, as that would cause progress bars to interrupt other information. For example, imagine there were a dialog which updated progress very soon after it was opened. That would cause the percentage indication to interrupt reporting of the dialog, which would be quite undesirable.

@bhavyashah
Copy link

@jcsteh I think I agree with your alternative approach. I concede that speech interrupt for reporting progress bar updates could be undesirable for the situation you described and similar ones. I suppose that reporting 10%, 20%...90%, 100% means that only 10 verbal announcements would be made which is reasonable. @feerrenrut Could you morph this issue (by editing the ticket title or description perhaps) to encompass only the bug identified in #4388 (comment)?

@jcsteh
Copy link
Contributor

jcsteh commented Aug 15, 2018

It looks like I might have been wrong in #4388 (comment). With this test case:

data:text/html,<progress id="progress" value="0"></progress><button onClick="update();">Start</button><script>function update() { progress.value += 0.05; setTimeout(update, 100); }</script>

Pressing the button starts moving the progress bar in 5% increments; 5%, 10%, 15%, etc. The beeps happen accordingly. Speech only reports in 10% increments starting at 5%; 5%, 15%, 25%, etc. So, this is working as expected.

@bhavyashah, based on your agreement that we shouldn't interrupt speech for these after all and given that I've confirmed the 10% increments are in fact working as expected, can we close this as works for me?

@Adriani90
Copy link
Collaborator

@jcsteh I suggest to Close this issue as well. Interupting speech in this Situation is definitely not the right way because notifications are then possibly ignored, i.e. in Windows 10.

@josephsl
Copy link
Collaborator

josephsl commented Jan 2, 2019

Hi,

But not until we hear from @bhavyashah confirming the existence of this bug in 2018.4, as there were changes made in event handling that may affect this issue. Thanks.

@Adriani90
Copy link
Collaborator

Unfortunately Bhavyah seems not to be available for a long time. I am closing this as works for me. Please comment on it if you are still having this problem and we can reopen the discussion. Note that you can press ctrl key and then NVDA will start speaking from the last current percentage onwards.

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

6 participants