Re: Gnopernicus and Screen Reading Philosophy (Was: Getting 320x200 in X ...)
On Mon, Aug 23, 2004 at 09:21:34AM +0300, Veli-Pekka Tatila wrote:
> Kenny Hitt wrote:
> >Most of Gnome is accessible with Gnopernicus, but Mozilla Evolution,
> >and Gnome's help system still aren't.
> That's too bad to hear. Umm how many of the 3rd party apps will work just
> fine? I'm a huge WInamp fan, and it would be great to use XMMS with
> Gnopernicus. Casual playing goes with mag only just fine, I suppose, but
> would be nice to have speech in the config dialogs.
>
Some of the GTK apps are accessible. The GUI version of alsamixer uses
GTK2, so it's accessible. Zinf uses GTK, but it still isn't accessible.
XMMS doesn't use GTK, so it isn't accessible. Until someone writes a
GTK2 interface for it, it won't be usable. You can hear the title of
the XMMS window when you switch to it, but you don't get any other info.
I'm a console user, so I use zinf, alsaplayer, mplayer, or ogg123 to
listen to audio. Mplayer can play Windows Media and Real audio streams.
It doesn't show the title info, so I use alsaplayer for MP3 streams.
Alsaplayer doesn't show the title for ogg streams, so I use ogg123 for
those. It sounds complicated, but I have scripts with the same name as
the stream I want to play. The script uses the player with the best
results for the stream and a playlist file to know the URL to play.
When a station changes it's playlist, I just have to download the new
one. Mplayer isn't an official Debian package, so I build it from
source. The other players are Debian packages, so apt-get install as
all you need.
> >One of the Gnome developers has started testing an alternitive written
> >mostly in python. It's advantage is it could maybe do scripting to
> >work around problems with accessing certain apps.
> Very interesting in one way, but pretty much not what I'd want to use
> frankly speaking. THis is getting off-topic but:
> On the Windows side I've always preferred Supernova to Jaws because of the
> philosophical differences about scripting and other automation. I think it
> is fine to have app-specific mapping and reading shortcuts, but under no
> circumstances should a screen reader do one of the following:
>
> -add new reader-specific keyboard shortcuts and interaction functionality
> that's not part of the app being made ----accessible. e.g. next heading in
> IE.
>
> -re-format, otherwise beautify or idealize objects on the screen to make
> them look or act differently and screen reader specifically. e.g. HTMl
> reformatting in Jaws 5.
>
> -modify your Windows/Linux settings by default without asking or telling
> you anything e.g. tampering with your keyboard refresh rates when the
> reader is running.
>
These shouldn't be problems with Linux screen readers. Linux really
supports multiple users. One user's settings don't have any effect on
others. My Gnome sessions use accessibility, my sighted user's accounts
don't.
> -listing info by default that sighted people would have trouble getting at.
> e.g. list counts. I think fuzzy info should be preferred in these cases.
>
> For more info, read my free screen reader ideas Web page:
>
> http://www.student.oulu.fi/~vtatila/free_screen_reader.html
>
> One thing that I have not had time to add yet is a point about
> cross-platform compatibility recently suggested to me. I don't have any
> real plans concerning the architecture yet but it would be absolutely great
> if the reader would be as portable as possible. You'd have some kind of an
> abstract off-screen model (OSM, perhaps using Swing-like ideas as the
> basis. You'd only need to re-implement classes that take care of
> translating OS-specific GUI widget to their abstract OSM counterparts to
> port the reader to another platform, at least in the ideal case.
>
> I would not want to start yet another religious screen reader war here.
> Rather, I'm just pointing out what my screen reader ideals would be.
> Supernova on the WIndows side and Gnopernicus in Linux are closest to those
> ideals so far.
>
I agree with most of your ideas about a GUI screen reader. When I used
Windows, I used JFW and Window-eyes. I prefered Window-eyes because it
gave me a more realistic idea of the apps display. One important
difference betwene Windows access and X-windows access is the
accessibility is built into the libs used to create the controls. This
means apps can be made accessible by just using the corect libs. You
don't need to worry about building an off screen model. When you use
layer 0 to review the screen in Gnopernicus, you are moving around the
data structure of the app's controls instead of something created after
the fact. The Gnome developers intend for all apps to be usable from
the keyboard. This means the only special keys should be for specific
screen reader commands. Gnopernicus only uses the keypad for it's
functions. All other keys are available to the app. As far as I can
tell, Orca doesn't have any special keys defined. The scripting part of
Orca is beeing used to work around problems which can't be easily fixed
in Gnopernicus. Orca has better access to Gnome-terminal because it
automatically reads the contents of the text control. It's doing the
equivalent of switching to flat review and going down the screen.
Your requirements could probably be met by Orca. It uses 3 C modules.
One to interface At-spi to python, one to use Gnome-speech
for speech output, and one to use rlapi for Braille output. You could
write the equivalent modules for Win32 and Orca would work in that OSS
as well. Your speech output module would use MSAPI, you would need
something that provided the screen data to Orca in the same data
structures. Same idea for your braille output module. It would be
harder to writhe the Windows modules, but it should be possible. I
believe KDE plans to use At-spi for it's accessibility, so getting
access to KDE might be easy with Orca. You should only need two modules
for KDE access. One to get access to KDE's accessibility interface, and
one to provide speech output. Since the braille output module doesn't
use anything specific to Gnome, it should work without any problems.
I'm not a developer, so my ideas could be completely wrong.
> >Gnopernicus, I have to use flat review mode to read the output from an ls
> >command.
> That sounds horrible. Can you run another screen reader, such as Yasr, in a
> terminal running in Gnome?
>
Yes you can use Yasr to get access to a terminal session, but I found it
easier to run Yasr in an Xterm instead of gnome-terminal. Gnopernicus
does get some info from gnome-terminal and I found it distracting to
hear both screen readers talking. Xterm isn't accessible, so
Gnopernicus stays quiet.
> Does a scripting language, such as Python, have much of a performance hit
> when it comes to implementing a screen reader? Do you notice any difference
> to Gnopernicus in real lief use? Also, why was Python used in stead of Perl?
>
It's hard for me to say for sure. I try running Gnome and Gnopernicus
on 1 of my computers that had Windows and noticed that Gnome and
Gnopernicus use more resources than Windows with software speech. I now
have fast computers, so I don't notice any difference from Gnopernicus
or Orca. I deleted my last Windows partition sometine in 2001, so I
can't really do a comparison. My observation was based on How I
remember Windows instead of switching betwene Windows and Linux.
I believe the developer of Orca chose Python because it is
flexible and easy to learn for newbys. If you add the necessiary
modules, Orca should work in Windows.
Hope this helps.
Kenny
Reply to: