I know that your example of Gmail was just an example, but I generally find that the built-in keystorkes that Gmail provides are significantly faster to navigate mail with than using the screen reader functionality.
Essentially, one can open a thread with "o" close a thread with "u", browse through the list of threads with "j" and "k" and navigate individual messages in a thread with "n" and "p".
Of course they also have keystrokes for replying, forwarding, deleting, archiving, and ignore thread.
On 10/21/18, 5:52 PM, "firstname.lastname@example.org on behalf of Tony Malykh" <email@example.com on behalf of firstname.lastname@example.org> wrote:
I have been noticing lately that many browse mode shortcuts are
sluggish in Google Chrome, especially on large web pages. Let me try
to explain what I mean with an example.
Suppose I open a large email thread (say 20 replies) in gmail in
Google Chrome. If I press H and then K, my cursor is supposed to find
the next heading, and then find the next link after that heading and
stop there. However, if I press them quickly one after the other, then
the after finding that link the cursor would jump back to the previous
heading as if I had pressed Shift+H afterwards. In other words, the
cursor would frirst find the heading, then jump to the next link, and
then it would mysteriously jump back to that heading again, all within
a short time, like within a second. I mentioned H and K just an
example - it seems that this issue can be reproduced with almost any
two browse mode commands, such as F, E, G, and so on.
Has anyone been aware of this issue? Are there any known workarounds?
One obvious workaround is for me to wait after every single browse
mode keystroke, but that would make using Chrome too anoying - I would
have to wait for about a second after pressing any browse mode
Actually I could reproduce this issue on the other browsers too -
Firefox and IE, although on a much lesser scale. In both Firefox and
IE you need to press these keystroeks really quickly together (maybe
less than 0.1 seconds apart to reproduce it, which probably wouldn't
affect anyone. This bug is only bothersome in Chrome.
I'm using the latest NVDA 2018.3.2 and the latest Windows 10. I have a
modern laptop, so this is not an issue of running out of CPU or
memory. I don't have too many tabs open and I don't have other