Problem with accessibility in R 4.2.0 and 4.2.1.
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 at 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel