Re: Navigating Text since NVDA 2017.3
Brian's Mail list account
I do agree about Github, though not for the reasons you state. I do feel its trying to be everything to everybody and is thus quite cluttered and opaque to a new user. Also when filling out new issues I'd far prefer separate fields for the questions than the in field suggestions on the current single field, as this is awkward to use for most people.toggle quoted messageShow quoted text
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Damien Sykes" <damien@...>
Sent: Thursday, December 07, 2017 12:30 AM
Subject: [nvda] Navigating Text since NVDA 2017.3
For anyone like me who has noticed the text lag and wonders why. The following came from Tyler Spivey, who helped me resolve this strange conundrum.
It actually appears that NVDA has always had some reason or other to have to wait a predetermined amount of time for the cursor to move in order to read whatever new information is under the cursor, or to inform of highlighted text, or if no change has occurred, to state the fact that we are at the beginning or end of the field. Until 2017.3, this was 30 milliseconds, a time so short that you would hardly notice it.
An entry in the change log for 2017.3 reads:
• In editable text, when moving the caret (e.g. with the cursor keys or backspace), NVDA's spoken feedback is now more accurate in many cases, particularly in Chrome and terminal applications.
In fact, one of the ways this seems to have been resolved was to increase the cursor wait time from 30 to 100 milliseconds, which may not seem much but is in fact a 230% increase. This means that people who are well tuned in to how NVDA read data previously, and perhaps more importantly rely on speed, will notice this change.
This is all apparently covered on GitHub, which, as far as I’m concerned isn’t really a user-friendly platform (that’s to say it’s meant for developers, and expert ones at that, which means you’re going to see a lot of technical jargon). Some may argue that this issue is a very fine line between a development technicality and usability, and since I seem to have been the only one who cared or even noticed this, I’m inclined to agree. But at least it’s out there now.
So, to summarise:
1. This is actually intended behaviour.
2. You can change it, but you have to know how and where it’s stored. It’s not in the configuration dialogs. Some may not even find it worth the effort – I only did because it ground straight through my sensitive teeth and pounded through my skull.
3. If you change it, be aware that you may not get the improved accuracy stated in the change log entry quoted above.