EditorGadget reads final lines incorrectly with screen readers

[Quin]

To reproduce, open a basic window with an editor gadget, like this while you have a screen reader running, and try to read it. With Narrator, you'll only hear the first character of the line when trying to read it, with NVDA you'll hear the entire content of the line on both lines, even the blank one. This doesn't appear to be a problem with RichEdit itself, Wordpad doesn't do it.

Code: Select all

OpenWindow(0, 0, 0, 600, 400, "Test")
EditorGadget(0, 5, 5, 400, 300)
AddGadgetItem(0, -1, "This is a test")
AddGadgetItem(0, -1, "")
SetActiveGadget(0)
Repeat : Until WaitWindowEvent(1) = #PB_Event_CloseWindow

[nsstudios]

I can reproduce.
This has always been a thing, but I thought all richedits did this.
Looking at the value of Wordpad's richedit50W control when I enter the same text as in this demo, I can see that the value is

Code: Select all

This is a test.\r\r

When doing the same with PB's richedit50W control, it has only a single

Code: Select all

\r

[Fred]

So it's a richedit thing ? You can add manually 2 br to behave like Wordpad ?

[nsstudios]

No. If I add another blank line in PB, screen reader sees three lines in total, but if I look at the value of the control, it shows up as two `\r's`.
In Wordpad, however, when screen reader sees two lines in total, the internal value seems to be two `\r's`. So there's always one more than in PB. Now whether the repeating of the last line in PB is because of this or not, I'm not sure, but just something I noticed.
Can be a bit problematic in PB's debug output, where if the last line is empty, you hear the contents of the second to last line when arrowing down. The same thing happens in any EditorGadget in PB.
I'm trying to think if I've seen the same behavior in other richedit controls, but I can't think of any off the top of my head.

[Quin]

PB's rich edit control is the only edit control I've seen do this. wxWidget's wxRichTextCtrl doesn't do it, nor does wordpad.
Good catch on the \rs nsstudios, I never would've thought to check that.

[Quin]

Something interesting I notice is that in wordpad's rich edit control, if I type a line of text and don't press enter, then try to left/right arrow to read by character, my screen reader will see a line feed as the last character, even though I didn't insert one. PB's EditorGadgets don't have this behavior.

[tspivey]

PB sends EM_SETTEXTMODE to the control with TM_PLAINTEXT. Put this before the first AddGadgetItem call:

Code: Select all

SendMessage_(GadgetID(0), #EM_SETTEXTMODE, #TM_RICHTEXT, 0)

And NVDA reads it correctly again. This sets the mode back to the default.

Maybe NVDA and Narrator weren't designed to handle rich text controls in that mode. I don't see any references to EM_GETTEXTMODE in NVDA's code.

[Fred]

Thanks for the tip, so I guess we will need to add a flag for richtext mode so it will be accessibility compliant (or switch back to RTF by default and add a flag for plaintext).

[Quin]

Personally, my vote is to have it be RTF by default, and have plain text be a flag

[Quin]

Just discovered that plaintext mode also makes pressing the down arrow key to read the current line as a screen reader user jump you to the end of the line, rather than maintaining your cursor position.
Screen readers really were not designed for plaintext mode I guess

[nsstudios]

Yeah that seems problematic because what if something else uses the plaintext flag as well? It's not PB's fault it's using a valid flag.
I don't know what the difference is accessibility notwithstanding, maybe there's a point to having plaintext flag turned on by def. Maybe it's faster?
I'm wondering if non-screen reader users find the difference important.
I'd love to hear from other forum people what they think. And Fred/Freak on the difference from the more technical side.

[Quin]

Sadly this one didn't get squashed in the 6.21 cycle. 6.22, or 6.30 hopefully?

[Fred]

It requiers a behaviour change, so we don't put it in minor release.

[BarryG]

Personally, my vote is to have it be RTF by default, and have plain text be a flag

+1. It's how it used to be, and we have StringGadgets for plain text anyway.

[Quin]

It requiers a behaviour change, so we don't put it in minor release.

Gotcha, thanks Fred. So 6.30 hopefully?