The tickt form on sourceforge isn't the easiest thing to use with a screen reader, and I'm not sure all the info I tried to give on this bug went through last time, so just in case:
when using a --text-info, the readonly text box doesn't present the text as you move through it with the arrows to orca. To reproduce:
f=mktemp;echo -e "line1\nline2\nline3" > $f;yad --text-info --filename $f;rm $f
The dialog is presented with a readonly text box containing:
line1
line2
line3
In the current version of yad, the read only box is focusable, but once focused, the arrow keys do not move through it. If you have orca running, no text is presented, and you can only get partial access by using flat review. To fix, you would have to allow a cursor to move through the dialog, and present the text to orca as an accessible object. Zenity is able to do this, I'm not sure if that is of any help to you though, can you maybe see what it does differently and make a fix based on that?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
what you mean when saying " the arrow keys do not move through it"?
i ran your example and i got a yad text window and able to scroll the text with arrow keys.
if you need to change currently focused element - use tab key
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, with some help from the Orca developer, I figured out what is going on. I guess zenity has carrot navigation enabled by default while the yad version does not. If I press F7 to toggle carrot navigation on, Orca works just fine with it. So, can an option be added to set carrot nav on for this dialog, or can it be set to carrot nav on when it is created?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And tell them to ignore this statement from the docs: "A buffer with no
editable text probably shouldn't have a visible cursor, so you may want
to turn the cursor off."
The tickt form on sourceforge isn't the easiest thing to use with a screen reader, and I'm not sure all the info I tried to give on this bug went through last time, so just in case:
when using a --text-info, the readonly text box doesn't present the text as you move through it with the arrows to orca. To reproduce:
f=mktemp;echo -e "line1\nline2\nline3" > $f;yad --text-info --filename $f;rm $f
The dialog is presented with a readonly text box containing:
line1
line2
line3
In the current version of yad, the read only box is focusable, but once focused, the arrow keys do not move through it. If you have orca running, no text is presented, and you can only get partial access by using flat review. To fix, you would have to allow a cursor to move through the dialog, and present the text to orca as an accessible object. Zenity is able to do this, I'm not sure if that is of any help to you though, can you maybe see what it does differently and make a fix based on that?
.
what you mean when saying " the arrow keys do not move through it"?
i ran your example and i got a yad text window and able to scroll the text with arrow keys.
if you need to change currently focused element - use tab key
Ok, with some help from the Orca developer, I figured out what is going on. I guess zenity has carrot navigation enabled by default while the yad version does not. If I press F7 to toggle carrot navigation on, Orca works just fine with it. So, can an option be added to set carrot nav on for this dialog, or can it be set to carrot nav on when it is created?
I had no more than hit post on the last reply when I got this message from the Orca list. The Orca developer says To take a look at the following link. I am pasting an excerpt from the message:
https://developer.gnome.org/gtk3/unstable/GtkTextView.html#gtk-text-view-set-cursor-visible
And tell them to ignore this statement from the docs: "A buffer with no
editable text probably shouldn't have a visible cursor, so you may want
to turn the cursor off."
Related aside, I just filed a bug against Gtk+ suggesting they remove
that statement. https://bugzilla.gnome.org/show_bug.cgi?id=762799
ok, i'll add appropriate option in next release
added in r937