You cannot move with arrows in read only edit boxes

[KevanGP]

Steps to reproduce:

Visit this webpage.
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_readonly
The last text box should be a read only box. When focused on it, I cannot arrow around to review information when in focus mode.

Actual behavior:

Country:
down arrow
edit read only Norway

NVDA+space
right arrow
cap N
right arrow
cap N
right arrow
cap N
right arrow
cap N
right arrow
cap N

Expected behavior:

The cursor should move when I arrow.

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

Install

NVDA version:

2022.4

Windows version:

Windows 10

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

Google Chrome Version 111.0.5563.65 (Official Build) (64-bit)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

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?

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

[CyrilleB79]

The problem is not present with Firefox (111) on the other hand.

[jcsteh]

Confirmed. This will need to be fixed in Chrome. I'm not sure whether the caret moves visually, but it certainly doesn't according to IAccessible2 (IAccessibleText::caretOffset always reports 0).

[jcsteh]

Distilled test case:
data:text/html,<input readonly value="abcd">

[CyrilleB79]

In Chrome, there is no cursor visible (at least with my low vision).

The edit field can take focus or not. And when it is focused, you can select all with control+A, then reduce or increase the selection moving the end selection point with shift+left/rightArrow. But if you decrease the selection with shift+left until the whole text is unselected, you cannot select again with shift+rightArrow.

[Adriani90]

cc: @aleventhal, @ObjectInSpace.

[jcsteh]

Incorrect as this is, NVDA users can cursor through the text using browse mode, so there is at least a trivial workaround.

[seanbudd]

Please report this to the chromium project.

[Adriani90]

Filled Chromium bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1433134

[Adriani90]

In the chromium bug it is argued that this should be fixed in screen readers by putting NVDA into a virtual buffer. Chromium devs will very probably not fix this issue themselves, Unless there is a WCA standard on how to handle caret movement in readonly text areas.

@jcsteh, @SaschaCowley since this is working as expected in Firefox, do you have any idea how to push this further to Chromium as well? I can see the benefits of navigating readOnly text areas in focus mode, but without a standard on caret movement I doubt we have any argument to push this further.
I commented my arguments about the benefits in the Chromium bug.
Imo it is too much effort to develop a virtual buffer especially for readOnly text boxes within the screen reader. Fixing this on browser's side should actually not be that hard.

[jcsteh]

I don't know if this is covered in WCAG, but most read only text box widgets (including native Win32 Edit controls and Firefox) support caret navigation. If they didn't, I don't really see the point of using a text box at all; why not just use a scrollable div?

I guess NVDA could work around this by switching to browse mode for read only text boxes, but only in Chromium, since we don't want to lose the proper caret functionality in Firefox. That is, NVDA's Chromium code could override shouldPassThrough to return False for read only text boxes.