Chrome Version: 61.0.3127.0 (Official Build) canary (64-bit)
OS: Windows 10 Version 1703 (OS Build 16199.1000) 64-bit
What steps will reproduce the problem?
(1) Start Chrome and the NVDA screen reader.
(2) Open this URL: data:text/html,<div contenteditable="true" role="combobox"><div>Hello there</div></div>
(3) Focus the contentEditable.
(4) Press control+home to move to the start of the text.
(5) Press control+left arrow to read the first word.
Expected: NVDA should say "Hello"
Actual: NVDA says "H"
(6) Press control+right arrow to move to and read the next word.
Expected: NVDA says "there"
Actual: NVDA says "t"
The word offsets returned from IAccessibleText for offsets 0 and 1 are (0, 1). For offset 2 and later, the returned word offsets are (0, 0).
It seems that when role="combobox" is used, the text is "flattened" into the combo box accessible; the exposed text is "Hello there". When you remove role="combobox", you get a single embedded object character instead (which refers to the accessible for the inner div). So, it seems that word offsets calculation thinks it's dealing with an embedded object character, even thoguh the exposed text is flattened.
I think IAccessibleText on a contentEditable with role="combobox" should behave the same way as a contentEditable with no role (or role="textbox"). That is, it should expose the embedded object character in the combo box accessible.
Impact: This breaks navigating by word when entering text in Facebook Messenger for Chrome + NVDA users.
Comment 1 by dmazz...@chromium.org
, Aug 4 2017