This is bug different from but related to 830113

The other bug, 830113, regards the focus highlight (default color: pink) that surrounds all of the text

This bug, 830116, regards the actual word highlighting within that focus highlight (default color: blue)

Like the other bug, this seems to be much more related to one-letter *nodes* and not one-letter *words*. It will also probably get worse as speech rate increases, due to stacked callbacks.

Please let me know how to tell the difference between one letter words and one letter nodes for testing purposes. Thanks!

Laura, in chrome://accessibility, compare this:
data:text/html,<a href="">A</a> a <a href="">B</a> b <a href="">C</a> c <a href="">D</a> d

to this:
data:text/html,A a B b C c D d

Note that the first one has a lot more staticText nodes, whereas the second only has one staticText node. But if you copy-paste the resulting html-formatted page into a plain text editor, you get the same result.

Does that make sense?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6599d2957cdea6c21bfb0d07f6844bd6efe7e4d6

commit 6599d2957cdea6c21bfb0d07f6844bd6efe7e4d6
Author: Katie D <katie@chromium.org>
Date: Fri Jul 13 23:21:14 2018

Fix STS highlight tracking short nodes and nodes separated by unspoken nodes.

Fixes a bug by using a "while" rather than an "if" when
stepping to the next node in word boundary events. This allows STS to
skip nodes if they are not spoken, which may occur if there are nodes
that are punctuation only in the list, like ")" or "-".

For example, on the English alphabet Wikipedia page, A a * B b * C c * etc,
the * node is not spoken, which causes highlight to get delayed because
those nodes could not be skipped. Changing the "if" to a "while" fixes that.

Bug:  830116 , 830116 
Change-Id: Ic40aa7c32ab10db3a084e94f1d4db49f096abd9c
Reviewed-on: https://chromium-review.googlesource.com/1136524
Reviewed-by: David Tseng <dtseng@chromium.org>
Commit-Queue: Katie Dektar <katie@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575113}
[modify] https://crrev.com/6599d2957cdea6c21bfb0d07f6844bd6efe7e4d6/chrome/browser/resources/chromeos/select_to_speak/select_to_speak.js

Google Chrome	69.0.3473.0 (Official Build) dev (64-bit)
Firmware Version	Google_Lulu.6301.136.57

I feel that this has fixed 830113 but not this bug per the original repro steps. 

Katie, please let me know what you think about this:


Attempting to verify based on the original repro steps and this comment: 
"For example, on the English alphabet Wikipedia page, A a * B b * C c * etc,
the * node is not spoken, which causes highlight to get delayed because
those nodes could not be skipped. Changing the "if" to a "while" fixes that." 

I am still seeing the bug behavior per this video: https://drive.google.com/file/d/1AeBhNaN9AcrtTD8d4Na_nsDDji4TGj8-/view

However, the case you gave me of using this HTML does not repro the bug behavior:

data:text/html,<a href="">A</a> a <a href="">B</a> b <a href="">C</a> c <a href="">D</a> d

Word highlight keeps up with the result from that html. 

Also, thanks for making this example above for me, much clearer. 

I just noticed that my Chromebook may not be updating in the Dev channel. Please let me know if I am not at the minimum version I need to be able to test this and then put the a11y-testers label back on please. Thanks! 

This landed in 69.0.3491.0.

To check where a change landed in the future, you can click on the googlesource link posted to the bug when the change landed (https://chromium.googlesource.com/chromium/src.git/+/6599d2957cdea6c21bfb0d07f6844bd6efe7e4d6), then "chrome", then "VERSION".

Google Chrome	70.0.3505.0 (Official Build) canary (64-bit)
Firmware Version	Google_Eve.9584.160.0

Verified using steps above.