[Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Tomas Kalibera]

On 9/22/22 18:24, peter dalgaard wrote:
> Tomas Kalibera has related that he has some scars from fighting with some unexpected interactions between UTF-8 and the GraphApp library that is used for RGui and I think he said that screen readers were involved. I wouldn't be surprised if this is a leftover issue. (This is obviously a kind of issue that non-blind users don't "see" :-) ).

Yes, that's almost surely related. GraphApp uses very different code for 
handling Windows messages in a multi-byte locale and single-byte locale, 
so switching to UTF-8 changed a lot. The multi-byte version hasn't been 
used that much before, and hence a number of bugs showed up after the 
switch.

> Would it work for you to use the terminal application (the "DOS box", or whatever it is called these days) until the issue gets fixed?
>
> In general, I would expect your go-to guy for blindness-related issues to be Jonathon Godfrey (cc'ed). Perhaps he can offer some advice.

There were two issues reported already with other software controlling a 
running window of Rgui, one was fixed in 4.2.1 (SendInput() for text 
injection didn't work in a multi-byte locale). Another hopefully was 
fixed in the application (it was using WM_CHAR messages to inject text, 
but that is not the right way to do this and fixing that to work as 
before would bee too difficult; the way recommended by Microsoft is 
SendInput, which now works).

It would be good if we could debug and fix this, on either end. For that 
we need to find out how the concrete screen reading applications 
communicate with Rgui window. Ideally I would have a tiny example which 
I could build and run on my Windows machine, without any special 
hardware, which would demonstrate the problem. Or, at least if the 
source code is available and we could have a look. Even if the 
application is closed source, the Windows messages could be captured by 
some tracing software to debug the protocol, and one could try writing 
an example/reproduction of the problem based on that.

Hopefully someone reading this could help with producing such an 
example, and then I could try investigating why it stopped working and 
fix, if possible.

In principle, we cannot yet assume that all Windows systems are new 
enough to support UTF-8 as the system encoding (also called ACP in 
Windows), so R support for running on Windows in a single-byte locale 
still cannot be removed, it will almost surely stay at least in 4.3. So, 
what I could definitely do is create an alternative build of Rgui which 
will use single-byte locale (like the older versions of R) even on new 
Windows systems. That alternatively build might be removed later if we 
decide to require UTF-8, but, temporarily it might help. Still, I hope 
we can debug and fix this to work properly when R is running with UTF-8 
as the native encoding.

I hope for now you can get away with 4.1.3. In principle, building Rgui 
to run R using single-byte locale is trivial (one just changes the 
manifest file for Rgui), so if a temporary solution was needed very 
fast, one can just do that and have a custom build before any new R 
release. Also, well, an older version of Windows 10 (or even older 
Windows) that don't support UTF-8 as the native encoding would do the same.

Best
Tomas


>
> -pd
>   
>
>> On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel <r-devel using r-project.org> wrote:
>>
>> Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this is the right place to ask about it. If it's not, I'm hoping someone can point me in the right direction.
>>
>> I'm blind and have been using R for about 11 years now. The base build available on CRAN is quite accessible and works pretty well with screen-reading software such as JAWS for Windows and NVDA. R-studio is not accessible which appears to have something to do with the version of QT it uses, but that's not relevant as I don't use it.
>>
>> Recently I installed R 4.2.1 (I tend to upgrade two or three times a year and this time I was jumping from R 4.1.2 to 4.2.1).
>> However, I've encountered a serious problem which makes the latest version more or less unusable for doing any kind of serious work.
>> The issue is that the screen-reading software is unable to locate the R cursor and behaves as though the cursor is near the top left of the R application window. Practically, this means I can't tell what characters I'm passing over when cursoring left and right, nor can I hear what character is being deleted when the backspace is pressed. Most importantly, I can't tell where the insertion point is. This is a major regression in the ability to work with and edit the command line in the R console. There are ways of actually viewing the command line but the way I work is frequently calling up a previous command and making a change so as to not have to type the whole command again.
>>
>> I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out exactly when things went awry and the issue first appeared in R 4.2.0.
>> Looking through the release notes, the only things mentioned that seem likely to be relevant are the following:
>>
>> • R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle had a different layout and can no longer be used.
>>
>> and
>>
>> • R uses UTF-8 as the native encoding on recent Windows systems (at least Windows 10 version 1903, Windows Server 2022 or Windows Server 1903). As a part
>> of this change, R uses UCRT as the C runtime. UCRT should be installed manually on systems older than Windows 10 or Windows Server 2016 before installing
>> R.
>>
>> I can't really see how changing to utf-8 as the native encoding would produce the behaviour I'm seeing, so I am guessing that the change in TCL/TK might be the culprit.
>>
>> I'm hoping that someone will be able to help shed some light on what's going on here.
>>
>> Thanks a lot,
>> Andrew.
>>
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel