Chrome Version: 61.0.3122.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" style="width: 100px; height: 100px;"></div>
(3) Focus the text box.
(4) Type "1" and press enter.
Expected: NVDA should say nothing.
Actual: NVDA says "1"
(5) Press NVDA+upArrow (laptop layout: NVDA+l) to read the current line.
Expected: NVDA should say "blank"
Actual: NVDA says "1"

When you press enter, a new div element is created in the contentEditable. This contains a br element. This br element is exposed as a line feed character, which makes sense. However, when you retrieve the line offsets for the "1" character (offset 0) in the parent accessible, Chrome includes the div that just got added; i.e. the offsets are (0, 2) instead of (0, 1). This causes the line feed character (at which the caret is positioned) to be treated as part of the previous line. This means that the user does not see a new blank line when they press enter. This is pretty confusing for speech, but would be even more so for braille.