Alright, played with this more and it definitely seems like the misspelled text marker is totally broken.

The core of the issue is that we're just not firing the right events to update the client trees (either automation or any other platform) to make this work.

For example,

if you have an initial snippet content editable with lots of text inside, the initial event doesn't populate the text markers.

Separately, but perhaps related, is if you begin to edit the misspelled word and arrow around, the indicies of the start/end of the misspelled word don't update. This is likely just that an event isn't fired to tyrigger an update of the client trees.

Finally, once you correct the misspelling and then re-introduce a misspelling, the word isn't again marked as misspelled.

We need to understand the Blink side and fire updates to ensure the client tree gets informed appropriately.

This is now blocking the feature in ChromeVox and is probably broken on other platforms.

 Issue 640479  has been merged into this issue.

Hello,
What is the status on this bug? It has almost been a year now and that is a long time for spellcheck to be completely broken in any application.
I think the text markers are also part of the bug that make editing in chrome with a screen reader impossible.
Can priority please be changed to 1 on this? No editing is a critical bug and Chrome should have not been released with such a big bug, but it has been like this for over a year and nothing seems to have changed.
Can the ball start rolling on this bug please?
Thank you,

THIS DOES  EFECT NVDA AS WELL THIS MAKES EDITING AN EMAIL NOT WORK AT ALL. 

I can confirm the same behavior in Google Chrome	64.0.3242.0 (Official Build) canary (64-bit) (cohort: 64-Bit) with NVDA 2017.3 and JAWS 2018.1710.33 (64bit) Public Beta. 

This was also reported to still be happening for an internal user. 

# Open NVDA and Gmail compose window in Chrome
# Misspell a word and press space
expected: chime or indication
actual: no indication
# use the arrow keys to put the cursor on the misspelled word 
expected: indication of misspelled word
actual: no indication

I see the same behavior with JAWS. 

635627 is now closed so I removed it from Blocking

I reproed this in Firefox 56.0 (64-bit) as well and saw this behavior with NVDA 2017.3 and JAWS 2018.1710.33 (64bit) Public Beta. 

# JAWS - no indication of misspelled words neither after typing the word nor when arrowing back on the misspelling 

# NVDA - after typing the misspelled word, a buzzer earcon is played and there are indications spoken that the word is misspelled