Moving line by line in this contentEditable box is not working as expected

[Adriani90]

Steps to reproduce:

This occurs both in Chrome and firefox.
Following test case:

data:text/html,<label for="wup5"><span contenteditable="true" role="textbox" aria-labelledby="wup5" style="white-space: pre-wrap">         there is enough multiline text       in this world           to produce a line long enough in order to be placed and wrapped in multi line contenteditable. Or maybe not? Who knows? Let's find out.     Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world </span><strong id="wup5">Test NVDA</strong> </label>

1. Open NVDA
2. Open the test case and switch to focus mode
3. Navigate with up and down arrow line by line, note the line is wraped after the third "hello world"

Actual behavior:

• Down arrow brings the caret at the end of the second line
• Up arrow brings the caret at the beginning of the first line.

Expected behavior:

system caret should be able to navigate line by line maintaining the horizontal position on the line. This works as expected in Jaws.

NVDA logs, crash dumps and other attachments:

n/a

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2024.4.1

Windows version:

Windows 11 23 H2

Name and version of other software in use when reproducing the issue:

Chrome Canary 133, Firefox 133

Other information about your system:

n/a

Other questions

Does the issue still occur after restarting your computer?

yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

no

If NVDA add-ons are disabled, is your problem still occurring?

yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

yes

[Adriani90]

cc: @jcsteh does it make sense to tweak the line by line navigation in NVDA to maintain the horizontal position of the system caret? This seems to be what Jaws does.
Or should we fill bugs with the browsers bug trackers to solve it there?
Not sure whether it occurs because there are only two lines in this contentEditable, but it causes a high inefficiency because it is not really possible to reach the beginning of the second line unless you navigate backwards character by character until you find the blank character (at least in Firefox).

[SaschaCowley]

With NVDA version alpha-34646,f0b36260 (2025.1.0.34646) and:

• Firefox 134.0b7 (64-bit): vertical navigation works the same with or without NVDA on - up arrow moves to the start of the wrapped content, down arrow moves to the end of the wrapped content
• Chrome Version 131.0.6778.109 (Official Build) (64-bit): vertical navigation works the same with or without NVDA - horizontal position is maintained when moving in a wrapped line.

IMO this is not an issue for NVDA to fix. The way the system caret moves in editable text arias is down to the application to handle, not the screen reader. I am going to leave this open until we officially triage it, but I am in favour of closing this as invalid.

[jcsteh]

I'm not entirely sure what is required by the spec. What I can say is that using a span here is odd, since a span is an inline element and normally isn't expected to be a block of multi-line text. In Firefox, using a span like this causes cursor navigation to treat the text as a single line, even though it wraps across lines. If you use a div (which is a block element), at least in Firefox, this works as expected.

[seanbudd]

Closing as invalid - this needs to be fixed in browsers. Screen reader usage doesn't effect STR.

[jcsteh]

I suspect this actually isn't even a browser bug, but rather authoring error. See my above comment re span vs div.

[SaschaCowley]

Does the spec disallow inline elements from being contenteditable? If not, I think that it would be perfectly legal for lines to wrap in them, just as lines can wrap (almost) anywhere else. It seems to me that this is just a difference in browser behaviour, unless the spec dictates the exact caret movement pattern (which seems unlikely given this really should match standard convention on the host platform).

[jcsteh]

Inline elements can definitely be contentEditable. However, inline elements and block elements are intended for fundamentally different purposes and thus behave in fundamentally different ways. I'm not sure what the spec says here, but given that this occurs in both Firefox and Chrome, changing this could be a web compat risk at the very least.

At any rate, this is not an accessibility specific issue. Filing bugs against the text editor components of browsers might at least get you an answer from the right people as to whether this is spec compliant or not, but I'm not going to put time into investigating this myself, and I doubt it's going to get priority given that it behaves consistently across browsers and given that using an inline element for a multi-line text box doesn't make a lot of sense.

[Adriani90]

Here is what MDN says about white-space: pre-wrap:

pre-wrap
Sequences of white space are preserved. Lines are broken at newline characters, at <br>, and as necessary to fill line boxes.
https://developer.mozilla.org/en-US/docs/Web/CSS/white-space

So this seems not really an authoring error I guess. If it is necessary, the text will be wrapped, and in my view this has an accessibility implication for braille users:

• With speech, you can hear where a line starts and when it ends
• With Braille, you usually pan the display and if the line has changed, the caret will appear at the beginning of the next line.

With the current behavior, braille users are not able to find out where the beginning of the second line is, because the caret jumps suddenly to the end of it after surpassing the wrap.
This becomes more relevant when the text box is very wide and the lines are very long.
So the current braille user story would be:

1. The user starts reading the first line in braille (caret is at the beginning of the line)
2. The line is very long, so it doesn't fit onto the display completely
3. The user pans the display to the right, the second part of the first line comes into view
4. The user pans futher (surpassing the line wrap)
5. The second part of the second line is shown, because the caret jumps to the end of the second line after surpassing the wrap.

This might result in confusions because the user would have to pan the braille display to the left in order to read the first part of the second line.

[SaschaCowley]

@Adriani90 does this actually happen, or is this just surmise?

[Adriani90]

Ah I just tested further with my Brailliant BI40X, it seems the braille display pans properly to the beginning of the next line, I don't know what caused this to fail yesterday.
So it seems yeah, only up and down arrow navigation is affected.

[jcsteh]

white-space: pre-wrap alone isn't the issue here. This only occurs if you wrap lines within an inline contentEditable. If you use a block contentEditable (e.g. div instead of span), the issue does not occur.

[jcsteh]

Note also that a span can be a block element depending on how it is styled. It's just inline by default. For example, this problem does not occur if you use a block span:

data:text/html,<label for="wup5"><span contenteditable="true" role="textbox" aria-labelledby="wup5" style="display: block; white-space: pre-wrap">%20%20%20%20%20%20%20%20 there is enough multiline text%20%20%20%20%20%20 in this world%20%20%20%20%20%20%20%20%20%20 to produce a line long enough in order to be placed and wrapped in multi line contenteditable. Or maybe not? Who knows? Let's find out.%20%20%20%20 Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world Hello world </span><strong id="wup5">Test NVDA</strong> </label>

[Adriani90]

Thanks Jamie for these valuable suggestions. Are these already considered in the a11y implications for the coresponding MDN articles? It is certainly worthy to have such a note at least on the MDN article for span or for contentEditable.

Indeed when using up and down arrow, on my braille display sometimes things get messed up, e.g. the second line is not displayed at all because the caret lands on a blank area at the end of the second line. But yeah, with your suggestions it seems to work as expected.

[jcsteh]

It's worth noting that what's actually happening here is that down arrow is moving to the end of the entire text, not specifically the second line. This is consistent with how down arrow behaves in a single line <input> element.