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

[Tomas Kalibera]

Hello Jonathan,

Rgui uses GraphApp as toolbox, but that is part of R source code and 
I've included into my summary of changes between 4.2.1 and 4.2.2, and I 
couldn't find anything that I think could impact the screen reader on 
the Rgui console. The changes in GraphApp are included also in NEWS, 
many of the fixes in Rgui are in fact in GraphApp. GraphApp then 
directly uses the Windows Graphics Device Interface (GDI). I am not 
aware of any such changes even between 4.2.0 and 4.2.1, either. So I 
have no clue why differences in screen reader performance were observed.


I've now tried with JAWS as well, the default installation, 40 minute 
trial. I did this experiment:


1. start Rgui
2. type "hello"
3. navigate back using left arrow

On R 4.0.5, 4.1.3, 4.2.1, 4.2.2, R-devel with the defaults (so 
"partial") cursor, JAWS worked fine and the same in all versions. It 
could read the letters back when I was navigating over them. It worked 
also with the "full" cursor. I didn't find any difference. I noticed 
that JAWS increased the cursor blink rate, which sighted people could 
find annoying.


Trying the same with NVDA.  "partial" cursor didn't work with any R 
version, the letters could be read when typed, but not when navigated 
back. The "full" cursor worked fine in R-devel (so with my recent 
fixes). In the released R versions I tested, I could make the "full" 
cursor work by switching focus (before step 3) by going to the "Edit" 
menu and back, e.g. "Alt+E followed by ESC followed by ESC".


So it looks like my fix wasn't needed for JAWS, but only for NVDA.

Of course my experiment is rather limited, if you or anyone else could 
test more scenarios and report any problems with the current R-devel 
Rgui (and the "full" cursor), it would be a great help and we can try to 
fix those.


Regarding changes that did happen to the R sources in the past, which 
clearly could impact the screen reader performance, I see R 2.12.0 has 
in NEWS: "The Rgui console now has an optional blinking caret (cursor) 
to assist screen readers for the visually impaired." Before this change, 
Rgui only used its custom drawn cursor, about which it didn't tell 
Windows, and hence Windows couldn't tell the screen readers. After this 
change, one could choose also "partial" (default) and "full" cursor. 
"partial" included the custom drawn cursor together with the standard 
Windows cursor ("caret") Windows knows about. "Full" cursor included 
only the standard Windows cursor. This was an addition by Duncan 
Murdoch, which allowed the navigation to work. "None" (none blinking) 
cursor in R 4.2.2 is like the original custom drawn cursor and neither 
NVDA nor JAWS with that can read the characters back when they are 
navigated over: they cannot detect the cursor.


I don't see any changes in the implementation of the cursor since the 
original Duncan's code for 2.12.0. I fixed some name clashes in 76745 in 
June 2019 (so R 4.0.0), but that should be completely benign.


However, what I did see was non-standard behavior of the standard 
Windows cursor in Rgui when switching windows, going to menu, starting 
Rgui, etc. I've fixed most but not (yet) all of those. It may be that 
users have ran into intermittent problems with the screen readers as a 
consequence of such actions (sometimes they lead not only to visually 
loosing the Windows cursor, but also to the cursor really disappearing 
so that Windows didn't know about it anymore). It is well possible that 
this also affected JAWS. I know for sure it did affect NVDA, based on 
which I did the current fixes.


Best
Tomas

On 12/21/22 20:33, Jonathan Godfrey wrote:

Hello both,

I so seldom use the RGUI that I hand't noticed it was behaving nicely in 4.2.2 
which has been running on my laptop for a long time!

I confirm the JAWS experience is back to what I expected prior to 4.2.0 and 
assure you that I do nothing to alter the default settings. I do think 
maintaining the usefulness of the GUI has merit because that is what a new R 
user will end up trying once they discover RStudio's inaccessibility.

I really do not understand how/why switching a cosmetic element of a cursor 
should lead to changes in the screen reader performance. I'm sure the size, 
shape, and colour of a mouse pointer  doesn't affect it's performance although 
I would expect it to have an impact on a user's performance.

Rather, I assumed that the change in the cosmetics of the cursor was the 
symptom of an underlying change that had multiple impacts, one of which was the 
disconnect with the screen reader.

Did the underlying development toolbox undergo any version changes from ( 
<4.2.0 ) to (4.2.0...4.2.1) to (4.2.2) ??

Great that normal transmission ha

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

[Jonathan Godfrey]

Hello both,

I so seldom use the RGUI that I hand't noticed it was behaving nicely in 4.2.2 
which has been running on my laptop for a long time!

I confirm the JAWS experience is back to what I expected prior to 4.2.0 and 
assure you that I do nothing to alter the default settings. I do think 
maintaining the usefulness of the GUI has merit because that is what a new R 
user will end up trying once they discover RStudio's inaccessibility.

I really do not understand how/why switching a cosmetic element of a cursor 
should lead to changes in the screen reader performance. I'm sure the size, 
shape, and colour of a mouse pointer  doesn't affect it's performance although 
I would expect it to have an impact on a user's performance.

Rather, I assumed that the change in the cosmetics of the cursor was the 
symptom of an underlying change that had multiple impacts, one of which was the 
disconnect with the screen reader. 

Did the underlying development toolbox undergo any version changes from ( 
<4.2.0 ) to (4.2.0...4.2.1) to (4.2.2) ??

Great that normal transmission has resumed.

Jonathan


-Original Message-
From: Tomas Kalibera  
Sent: Thursday, 22 December 2022 6:53 am
To: Andrew Hart ; Jonathan Godfrey 

Cc: R-devel@r-project.org
Subject: Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

Hi Andrew,

thanks a lot for your testing and I am looking forward to what you find 
out about the fixes in R-devel.

You asked about changes between 4.2.1 and 4.2.2 relevant to this. I 
don't think you overlooked anything, I looked now again at the source 
code diff and I didn't find anything relevant. The Rgui console was 
fixed to work with Alt+sequences (tilde on Italian keyboard). GraphApp 
was fixed to use the correct font charset for UTF-8 in dialog boxes. 
Search and replace was fixed in the script editor. Invalid write was 
fixed with printing very long lines.

None of those changes should impact the behavior of the caret in the 
console window. I would not be surprised if the behavior with the screen 
reader was unpredictable/random, certainly inconsequential to whether we 
had R 4.2.1 or 4.2.2. Hopefully the changes now in R-devel would make it 
more reliable. If not, we can try to improve it further.

Thanks for testing with JAWS, I am impressed it can get anything out 
from Rgui with the partial cursor. NVDA cannot, it allows navigating 
using left arrow/right arrow over the line (after focus out+in in R 
4.2.2), but it thinks that the characters on the line are all spaces.

In either case, I think using the partial cursor with screen readers 
doesn't make sense, it could only confuse the screen reader application. 
If some people preferred a wider cursor than "full", we could add a 
"wide full" cursor, that would be quite easy. If some people preferred 
less blinking or no blinking at all, they can already set that up 
system-wide in Windows for the "full" (or potential "wide full") cursor.

Cheers
Tomas

On 12/21/22 17:12, Andrew Hart wrote:
> HI Tomas,
>
> Thanks a lot for not letting this go. It is truly appreciated. I had 
> been using Rterm directly as Jonathan had suggested since we discussed 
> this a number of months ago on the R-devel list. However, about a week 
> and a half ago I accidentally launched Rgui for R 4.2.2 (which I 
> installed around the end of October) and was surprised when I could 
> actually  use it like I could use the pre-4.2 versions of R! I have 
> been using it for a little more than a week now and was intending to 
> write to you, but you beat me with this message.
> The accessibility of Rgui 4.2.2 seems very similar to R 4.1.2 (which I 
> still have on my system). In contrast, Rgui 4.2.1 is more or less 
> unusable. I was wanting to ask you if perhaps something got changed in 
> R 4.2.2? Nothing jumped out at me in the release notes, but I could 
> easily have overlooked something.
>
> After reading this message, I went and checked the cursor blink 
> setting in my 4.2.2 installation and it is indeed set to partial. 
> You're right in that occasionally JAWS loses the cursor and the 
> ability to read the R window. However, simply pressing the  key 
> while Rgui has the focus fixes this. It seems that drawing a new 
> command prompt on a new line sets JAWS straight and I am able to keep 
> working. I haven't used 4.1.2 for a while, but I think it had the same 
> issue. I assumed that this was caused by moving from Windows 7 to 
> Windows 10, since I never encountered this kind of issue in windows 7. 
> I'll try out full cursor and see if that makes a difference in 4.2.2.
>
> Also, I'll download the development snapshot and try it out. I'll let 
> you know how I get on. Please excuse me if I don't get to it 
> immediately; things are a bit c

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

[Tomas Kalibera]

Hi Andrew,

thanks a lot for your testing and I am looking forward to what you find 
out about the fixes in R-devel.


You asked about changes between 4.2.1 and 4.2.2 relevant to this. I 
don't think you overlooked anything, I looked now again at the source 
code diff and I didn't find anything relevant. The Rgui console was 
fixed to work with Alt+sequences (tilde on Italian keyboard). GraphApp 
was fixed to use the correct font charset for UTF-8 in dialog boxes. 
Search and replace was fixed in the script editor. Invalid write was 
fixed with printing very long lines.


None of those changes should impact the behavior of the caret in the 
console window. I would not be surprised if the behavior with the screen 
reader was unpredictable/random, certainly inconsequential to whether we 
had R 4.2.1 or 4.2.2. Hopefully the changes now in R-devel would make it 
more reliable. If not, we can try to improve it further.


Thanks for testing with JAWS, I am impressed it can get anything out 
from Rgui with the partial cursor. NVDA cannot, it allows navigating 
using left arrow/right arrow over the line (after focus out+in in R 
4.2.2), but it thinks that the characters on the line are all spaces.


In either case, I think using the partial cursor with screen readers 
doesn't make sense, it could only confuse the screen reader application. 
If some people preferred a wider cursor than "full", we could add a 
"wide full" cursor, that would be quite easy. If some people preferred 
less blinking or no blinking at all, they can already set that up 
system-wide in Windows for the "full" (or potential "wide full") cursor.


Cheers
Tomas

On 12/21/22 17:12, Andrew Hart wrote:

HI Tomas,

Thanks a lot for not letting this go. It is truly appreciated. I had 
been using Rterm directly as Jonathan had suggested since we discussed 
this a number of months ago on the R-devel list. However, about a week 
and a half ago I accidentally launched Rgui for R 4.2.2 (which I 
installed around the end of October) and was surprised when I could 
actually  use it like I could use the pre-4.2 versions of R! I have 
been using it for a little more than a week now and was intending to 
write to you, but you beat me with this message.
The accessibility of Rgui 4.2.2 seems very similar to R 4.1.2 (which I 
still have on my system). In contrast, Rgui 4.2.1 is more or less 
unusable. I was wanting to ask you if perhaps something got changed in 
R 4.2.2? Nothing jumped out at me in the release notes, but I could 
easily have overlooked something.


After reading this message, I went and checked the cursor blink 
setting in my 4.2.2 installation and it is indeed set to partial. 
You're right in that occasionally JAWS loses the cursor and the 
ability to read the R window. However, simply pressing the  key 
while Rgui has the focus fixes this. It seems that drawing a new 
command prompt on a new line sets JAWS straight and I am able to keep 
working. I haven't used 4.1.2 for a while, but I think it had the same 
issue. I assumed that this was caused by moving from Windows 7 to 
Windows 10, since I never encountered this kind of issue in windows 7. 
I'll try out full cursor and see if that makes a difference in 4.2.2.


Also, I'll download the development snapshot and try it out. I'll let 
you know how I get on. Please excuse me if I don't get to it 
immediately; things are a bit crazy at work at the moment and it is 
that time of the year too!


Cheers,
Andrew.

On 20/12/2022 19:33, Tomas Kalibera wrote:

Dear Andrew, Jonathan,

I had a closer look and tried to improve accessibility in Rgui, 
please see below. I would be grateful for feedback.


Rgui supports three cursor types, which can be selected via Edit/GUI 
preferences/Cursor blink.


The default is "partial", but for screen readers, please use "full". 
You can change the selection in the menu and then "Save..." to save 
it into your Rconsole file. If you already have the file, the 
corresponding selection is "cursor_blink = Full".


The "full" cursor is implemented as the standard Windows "caret" and 
this is what screen readers can see. Once you set this cursor as the 
default in your Rconsole file and re-start Rgui, but before you start 
using the console, please switch focus out and back in (e.g. press 
Alt+TAB twice). This helps NVDA detect the characters under the 
cursor in already released versions of R. Please start the screen 
reader before starting Rgui.


I found that the "full" cursor implementation has a number of 
problems: in some situation it disappears when it shouldn't, in some 
the other way around. I thought this was confusing the screen reader, 
so I fixed most of these cases.


However, the true cause was that Rgui didn't create the cursor right 
when it got focus the first time. Luckily NVDA is open-source, so one 
can read and modify the source code to find out. I've added a 
work-around to Rgui, which is used only with the "full" cursor, 
because the "partial" cur

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

[Andrew Hart via R-devel]

HI Tomas,

Thanks a lot for not letting this go. It is truly appreciated. I had 
been using Rterm directly as Jonathan had suggested since we discussed 
this a number of months ago on the R-devel list. However, about a week 
and a half ago I accidentally launched Rgui for R 4.2.2 (which I 
installed around the end of October) and was surprised when I could 
actually  use it like I could use the pre-4.2 versions of R! I have been 
using it for a little more than a week now and was intending to write to 
you, but you beat me with this message.
The accessibility of Rgui 4.2.2 seems very similar to R 4.1.2 (which I 
still have on my system). In contrast, Rgui 4.2.1 is more or less 
unusable. I was wanting to ask you if perhaps something got changed in R 
4.2.2? Nothing jumped out at me in the release notes, but I could easily 
have overlooked something.


After reading this message, I went and checked the cursor blink setting 
in my 4.2.2 installation and it is indeed set to partial. You're right 
in that occasionally JAWS loses the cursor and the ability to read the R 
window. However, simply pressing the  key while Rgui has the 
focus fixes this. It seems that drawing a new command prompt on a new 
line sets JAWS straight and I am able to keep working. I haven't used 
4.1.2 for a while, but I think it had the same issue. I assumed that 
this was caused by moving from Windows 7 to Windows 10, since I never 
encountered this kind of issue in windows 7. I'll try out full cursor 
and see if that makes a difference in 4.2.2.


Also, I'll download the development snapshot and try it out. I'll let 
you know how I get on. Please excuse me if I don't get to it 
immediately; things are a bit crazy at work at the moment and it is that 
time of the year too!


Cheers,
Andrew.

On 20/12/2022 19:33, Tomas Kalibera wrote:

Dear Andrew, Jonathan,

I had a closer look and tried to improve accessibility in Rgui, please 
see below. I would be grateful for feedback.


Rgui supports three cursor types, which can be selected via Edit/GUI 
preferences/Cursor blink.


The default is "partial", but for screen readers, please use "full". You 
can change the selection in the menu and then "Save..." to save it into 
your Rconsole file. If you already have the file, the corresponding 
selection is "cursor_blink = Full".


The "full" cursor is implemented as the standard Windows "caret" and 
this is what screen readers can see. Once you set this cursor as the 
default in your Rconsole file and re-start Rgui, but before you start 
using the console, please switch focus out and back in (e.g. press 
Alt+TAB twice). This helps NVDA detect the characters under the cursor 
in already released versions of R. Please start the screen reader before 
starting Rgui.


I found that the "full" cursor implementation has a number of problems: 
in some situation it disappears when it shouldn't, in some the other way 
around. I thought this was confusing the screen reader, so I fixed most 
of these cases.


However, the true cause was that Rgui didn't create the cursor right 
when it got focus the first time. Luckily NVDA is open-source, so one 
can read and modify the source code to find out. I've added a 
work-around to Rgui, which is used only with the "full" cursor, because 
the "partial" cursor confuses the screen reader too much to be usable, 
anyway. So, after this fix, one doesn't have to do that focus out+in trick.


The improvements are in R-devel (revision 83482 or newer). I would be 
grateful if you could test it, so that it could be improved further (or 
reverted if it actually turned out worse). Particularly if you find a 
problem reproducible with NVDA, that should be something I could 
diagnose and improve, as I have the sources.


I've been testing with NVDA and I'd be curious about the impact on JAWS.
Rgui doesn't work with Narrator.

Thanks,
Tomas

On 9/22/22 23:15, Andrew Hart via R-devel wrote:

On 22/09/2022 16:42, Toby Hocking wrote:
Another option is to use https://emacspeak.sourceforge.net/ 
 (version of emacs editor/ide 
which can speak letters/words/lines -- has a blind maintainer) with 
https://ess.r-project.org/  (interface 
for editing and running R code from within emacs)


Thanks everyone for all the suggestions. Of course, the optimal 
solution would be to figure out what is going on in Rgui, but, as is 
always the case, the blind user use case is a fairly niche one. I 
appreciate all the suggestions for finding an immediate solution to my 
problem.
I don't use any kind of IDE for working with R since I simply haven't 
found one that is accessible or that i understand how to use. There is 
a plug-in for the Eclipse IDE I installed a few years ago, but I 
didn't understand the first thing about how it was to be used. So I've 
just always worked with an editor open in one Window and R in another,
working interactively in R or bouncing over to the editor for

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

[Tomas Kalibera]

Dear Andrew, Jonathan,

I had a closer look and tried to improve accessibility in Rgui, please 
see below. I would be grateful for feedback.


Rgui supports three cursor types, which can be selected via Edit/GUI 
preferences/Cursor blink.


The default is "partial", but for screen readers, please use "full". You 
can change the selection in the menu and then "Save..." to save it into 
your Rconsole file. If you already have the file, the corresponding 
selection is "cursor_blink = Full".


The "full" cursor is implemented as the standard Windows "caret" and 
this is what screen readers can see. Once you set this cursor as the 
default in your Rconsole file and re-start Rgui, but before you start 
using the console, please switch focus out and back in (e.g. press 
Alt+TAB twice). This helps NVDA detect the characters under the cursor 
in already released versions of R. Please start the screen reader before 
starting Rgui.


I found that the "full" cursor implementation has a number of problems: 
in some situation it disappears when it shouldn't, in some the other way 
around. I thought this was confusing the screen reader, so I fixed most 
of these cases.


However, the true cause was that Rgui didn't create the cursor right 
when it got focus the first time. Luckily NVDA is open-source, so one 
can read and modify the source code to find out. I've added a 
work-around to Rgui, which is used only with the "full" cursor, because 
the "partial" cursor confuses the screen reader too much to be usable, 
anyway. So, after this fix, one doesn't have to do that focus out+in trick.


The improvements are in R-devel (revision 83482 or newer). I would be 
grateful if you could test it, so that it could be improved further (or 
reverted if it actually turned out worse). Particularly if you find a 
problem reproducible with NVDA, that should be something I could 
diagnose and improve, as I have the sources.


I've been testing with NVDA and I'd be curious about the impact on JAWS.
Rgui doesn't work with Narrator.

Thanks,
Tomas

On 9/22/22 23:15, Andrew Hart via R-devel wrote:

On 22/09/2022 16:42, Toby Hocking wrote:
Another option is to use https://emacspeak.sourceforge.net/ 
 (version of emacs editor/ide 
which can speak letters/words/lines -- has a blind maintainer) with 
https://ess.r-project.org/  (interface 
for editing and running R code from within emacs)


Thanks everyone for all the suggestions. Of course, the optimal 
solution would be to figure out what is going on in Rgui, but, as is 
always the case, the blind user use case is a fairly niche one. I 
appreciate all the suggestions for finding an immediate solution to my 
problem.
I don't use any kind of IDE for working with R since I simply haven't 
found one that is accessible or that i understand how to use. There is 
a plug-in for the Eclipse IDE I installed a few years ago, but I 
didn't understand the first thing about how it was to be used. So I've 
just always worked with an editor open in one Window and R in another,
working interactively in R or bouncing over to the editor for more 
complex things and sourcing code into R as necessary. However, I only 
use the R console in Rgui. I went and had a look at Rterm, which I 
have never used on Windows; I've only ever used it when ssh-ing into 
Linux systems to use R. However, I've just found out that Rterm does a 
number of fairly important things that probably mean I can just use it 
instead of Rgui:

1. You can paste from the clipboard into the Rterm prompt;
2. It has a command history;
3. If you plot something, it opens a Window to draw the plot (I never 
realised it could do this and had always assumed Rgui was needed for 
this); and
4. It opens the HTML help if you ask for help on windows. I only ever 
saw it display text help on Linux, but I was logged in remotely. 
Text-based help is fine when ssh-ing into a machine, but HTML help is 
much nicer to read and navigate.


I think I'll just switch over to Rterm for a while, but I can also 
check out ess, which I wasn't aware of.


Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Tomas Kalibera]

On 9/22/22 23:15, Andrew Hart via R-devel wrote:

On 22/09/2022 16:42, Toby Hocking wrote:
Another option is to use https://emacspeak.sourceforge.net/ 
 (version of emacs editor/ide 
which can speak letters/words/lines -- has a blind maintainer) with 
https://ess.r-project.org/  (interface 
for editing and running R code from within emacs)


Thanks everyone for all the suggestions. Of course, the optimal 
solution would be to figure out what is going on in Rgui, but, as is 
always the case, the blind user use case is a fairly niche one. I 
appreciate all the suggestions for finding an immediate solution to my 
problem.
I don't use any kind of IDE for working with R since I simply haven't 
found one that is accessible or that i understand how to use. There is 
a plug-in for the Eclipse IDE I installed a few years ago, but I 
didn't understand the first thing about how it was to be used. So I've 
just always worked with an editor open in one Window and R in another,
working interactively in R or bouncing over to the editor for more 
complex things and sourcing code into R as necessary. However, I only 
use the R console in Rgui. I went and had a look at Rterm, which I 
have never used on Windows; I've only ever used it when ssh-ing into 
Linux systems to use R. However, I've just found out that Rterm does a 
number of fairly important things that probably mean I can just use it 
instead of Rgui:

1. You can paste from the clipboard into the Rterm prompt;
2. It has a command history;
3. If you plot something, it opens a Window to draw the plot (I never 
realised it could do this and had always assumed Rgui was needed for 
this); and
4. It opens the HTML help if you ask for help on windows. I only ever 
saw it display text help on Linux, but I was logged in remotely. 
Text-based help is fine when ssh-ing into a machine, but HTML help is 
much nicer to read and navigate.


I think I'll just switch over to Rterm for a while, but I can also 
check out ess, which I wasn't aware of.


Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Tomas Kalibera]

On 9/22/22 23:15, Andrew Hart via R-devel wrote:

On 22/09/2022 16:42, Toby Hocking wrote:
Another option is to use https://emacspeak.sourceforge.net/ 
 (version of emacs editor/ide 
which can speak letters/words/lines -- has a blind maintainer) with 
https://ess.r-project.org/  (interface 
for editing and running R code from within emacs)


Thanks everyone for all the suggestions. Of course, the optimal 
solution would be to figure out what is going on in Rgui, but, as is 
always the case, the blind user use case is a fairly niche one. I 
appreciate all the suggestions for finding an immediate solution to my 
problem.


Hi Andrew,

I am glad to hear that Rterm seems to be working for you, but I would 
still like to see if Rgui could be improved to work as well.


I am completely new to screen readers, but I learned that NVDA is free 
and open-source and doesn't need any special hardware. So I installed it 
on my system.


When I enter something to the current line in Rterm console and navigate 
over the typed letters using left/right arrow, NVDA reads the character 
at the cursor.


When I enter something to the current line in Rgui console (executed in 
the default way), NVDA either doesn't read anything when I navigate over 
the typed characters or it reads incorrect characters. Is this a 
reproduction of the problem you are reporting? Or, how could I reproduce 
the problem you are seeing with NVDA?


Now, for me, even Rgui from R 4.0.5 and R 4.1.3 has the problem: the 
characters read are either wrong (usually space and newline), or no 
characters are read at all.


Also, I tried building R-devel modified so that Rgui doesn't use UTF-8 
as the system/R native encoding. It didn't change anything: NVDA still 
can't read the characters when navigating.


Best
Tomas



I don't use any kind of IDE for working with R since I simply haven't 
found one that is accessible or that i understand how to use. There is 
a plug-in for the Eclipse IDE I installed a few years ago, but I 
didn't understand the first thing about how it was to be used. So I've 
just always worked with an editor open in one Window and R in another,
working interactively in R or bouncing over to the editor for more 
complex things and sourcing code into R as necessary. However, I only 
use the R console in Rgui. I went and had a look at Rterm, which I 
have never used on Windows; I've only ever used it when ssh-ing into 
Linux systems to use R. However, I've just found out that Rterm does a 
number of fairly important things that probably mean I can just use it 
instead of Rgui:

1. You can paste from the clipboard into the Rterm prompt;
2. It has a command history;
3. If you plot something, it opens a Window to draw the plot (I never 
realised it could do this and had always assumed Rgui was needed for 
this); and
4. It opens the HTML help if you ask for help on windows. I only ever 
saw it display text help on Linux, but I was logged in remotely. 
Text-based help is fine when ssh-ing into a machine, but HTML help is 
much nicer to read and navigate.


I think I'll just switch over to Rterm for a while, but I can also 
check out ess, which I wasn't aware of.


Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Jonathan Godfrey]

Hello all,

I can confirm Andrew's assessment of the situation for screen reader users 
(both JAWS and NVDA) for R GUI version 4.2.1; I don't intend to go back and 
verify how/when the problem first arose though.

The situation is not new, or at least the same experience was evident well 
before now. When I started using R around 2005/6, the experience we now see 
today was how I found the GUI then. I investigated the terminal which was a 
huge success and never looked back.

I tracked how the R GUI was going because my students would be using it, and at 
some stage, the way the GUI cursor behaved changed. If I recall correctly, the 
physical appearance of the cursor also altered at the same time. I still update 
versions regularly to stay one step of my students (all sighted) but because no 
one uses the R GUI, my efforts to trace its behaviour have been dwindling over 
the last five or so years. I don't need to check the RStudio behaviour because 
I can't, my colleagues are doing so, and I know it won't change for blind 
people anytime soon.

The terminal has behaved consistently all that time. It has some minor 
differences between JAWS and NVDA, but the user knows what their screen reader 
is doing so the differences have relatively minor impact. It remains how I use 
R and therefore what I recommend for other blind users. N.B. I also strongly 
recommend R markdown files over R scripts.

The experience in the GUI was human dependent, with the choice of screen reader 
and the skill level of the users with their screen reader both having an impact 
on the overall user experience. For many years, NVDA users were better off in 
the GUI than in the terminal, while most JAWS users were happier in the 
terminal. It has been fairly fluid though so my advice has been to try, using 
the existing skills and screen reader, but to be prepared to revert to the 
terminal fairly quickly.

Minor variations in the interactions of R GUI and the various screen readers 
mean the difference between JAWS and NVDA were very similar prior to v4.2.0 to 
the extent that I would say the experience had converged quite nicely.

RStudio has not made any significant progress in making its IDE more 
accessible, and I fear that it never will. I have tested other front ends and 
none have yet met accessibility standards. The problem with most of the front 
ends is that they are using development toolkits (such as QT) that do not speak 
with screen readers straight out of the box. I mentioned this in my R Journal 
article back in 2013.

I fear that the development toolkit problem is what compromises accessibility 
of R GUI too. In a discussion I had with Duncan at UseR 2015, it was obvious to 
me that nothing  intentional had been done to the R GUI to improve my initial 
experience to the situation Andrew has been enjoying. For that reason, I 
suspect that there is room for something different in the background, as 
against any explicit action taken by the R developments, which have 
(unfortunately) taken us backwards.

Andrew: I am confident you can move to the terminal without requiring help, but 
grabbing the latest development version of BrailleR off GitHub will give you 
some functions that will save a bit of effort. We might arrange a voice call 
next week for an ongoing discussion.

Tomas: I'm not able to help with your suggestion, mainly because I don't 
understand the nuts and bolts of it. I do believe though that the cursor focus 
is a critical factor, but that the cursor being used by the screen reader 
software is different to the cursor being used by the sighted users. When I 
switch from the active cursor to the screen readers' review mode, the screen 
readers both take me back to the top left of the window under the menu bar. Has 
anything changed in the visual appearance of the cursor from v4.1.3 to v4.2.0? 
I ask because it is the symptom.

Peter: Thank you very much for actively bringing me into this thread. I don't 
know why I hadn't seen Andrew's first message given I get other list traffic.

Jonathan


-Original Message-
From: peter dalgaard  
Sent: Friday, 23 September 2022 4:24 am
To: Andrew Hart 
Cc: R-devel@r-project.org; Tomas Kalibera ; Jonathan 
Godfrey 
Subject: Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

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" :-) ).

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

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

[Tomas Kalibera]

t 
Cc: R-devel@r-project.org; Tomas Kalibera ; Jonathan 
Godfrey 
Subject: Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

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" :-) 
).

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.

-pd
  


On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel  
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@r-project.org mailing list
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=05%7C01%7CA.J.Godfrey%40massey.ac.nz%7C3e0ccf59e1204914ed8d08da9cb6e77e%7C388728e1bbd0437898dcf8682e644300%7C1%7C0%7C637994606638298455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rkn809t40%2BbzwxC%2BVUkQcna4SkaoupyZG%2F1ZMgCw%2BGE%3D&reserved=0


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Andrew Hart via R-devel]

On 22/09/2022 16:42, Toby Hocking wrote:
Another option is to use https://emacspeak.sourceforge.net/ 
 (version of emacs editor/ide which 
can speak letters/words/lines -- has a blind maintainer) with 
https://ess.r-project.org/  (interface for 
editing and running R code from within emacs)


Thanks everyone for all the suggestions. Of course, the optimal solution 
would be to figure out what is going on in Rgui, but, as is always the 
case, the blind user use case is a fairly niche one. I appreciate all 
the suggestions for finding an immediate solution to my problem.
I don't use any kind of IDE for working with R since I simply haven't 
found one that is accessible or that i understand how to use. There is a 
plug-in for the Eclipse IDE I installed a few years ago, but I didn't 
understand the first thing about how it was to be used. So I've just 
always worked with an editor open in one Window and R in another,
working interactively in R or bouncing over to the editor for more 
complex things and sourcing code into R as necessary. However, I only 
use the R console in Rgui. I went and had a look at Rterm, which I have 
never used on Windows; I've only ever used it when ssh-ing into Linux 
systems to use R. However, I've just found out that Rterm does a number 
of fairly important things that probably mean I can just use it instead 
of Rgui:

1. You can paste from the clipboard into the Rterm prompt;
2. It has a command history;
3. If you plot something, it opens a Window to draw the plot (I never 
realised it could do this and had always assumed Rgui was needed for 
this); and
4. It opens the HTML help if you ask for help on windows. I only ever 
saw it display text help on Linux, but I was logged in remotely. 
Text-based help is fine when ssh-ing into a machine, but HTML help is 
much nicer to read and navigate.


I think I'll just switch over to Rterm for a while, but I can also check 
out ess, which I wasn't aware of.


Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [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  
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.
Look

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

[Toby Hocking]

Another option is to use https://emacspeak.sourceforge.net/ (version of
emacs editor/ide which can speak letters/words/lines -- has a blind
maintainer) with https://ess.r-project.org/ (interface for editing and
running R code from within emacs)

On Thu, Sep 22, 2022 at 9:42 AM Duncan Murdoch 
wrote:

> On 22/09/2022 9:48 a.m., Andrew Hart via R-devel 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.
>
> I believe RStudio is in the process of moving away from QT to Electron.
>   I don't know when the non-QT version will be released (if not
> already), but you might want to investigate that if Rgui doesn't work out.
>
> Duncan Murdoch
> >
> > 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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Duncan Murdoch]

On 22/09/2022 9:48 a.m., Andrew Hart via R-devel 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.


I believe RStudio is in the process of moving away from QT to Electron. 
 I don't know when the non-QT version will be released (if not 
already), but you might want to investigate that if Rgui doesn't work out.


Duncan Murdoch


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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[peter dalgaard]

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" :-) ).

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.

-pd
 

> On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel  
> 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[Ben Bolker]

  There was a long apparently related thread back in May:

https://stat.ethz.ch/pipermail/r-devel/2022-May/081708.html

but that problem was supposedly patched in 4.2.1 ...


On 2022-09-22 9:48 a.m., Andrew Hart via R-devel 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of 
working hours.


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel