Re: X Accessibility (Was: Gnopernicus ...)
Kenny Hitt wrote:
The GUI version of alsamixer
uses GTK2, so it's accessible.
Ah very nice,. One thing that really sucks in terms of usability, though, is
that there can often be so many channels that you'll actually have to scroll
around the mixer to see them all. I wonder if it auto-scrolls if you tab
from slider to slider?
Zinf uses GTK, but it still isn't
accessible.
Umm if I'm reading this correctly, does this imply that all GTK1 apps are
automagically inaccessible and GTK2 apps accessible, respectively. Might a
GTK1 to GTK2 wrapper solve this problem cleanly?
Also, I've read about a project that uses QT to render GTK widgets. If this
process is nearly symmetric, I suppose it would be relatively easy to do it
the other way round, that is mapping QT to GTK widgets. Would QT-apps be
mostly accessible this way or does GTK include some extra accessibility
support that you cannot get when wrapping from QT widgets?
In addition, here's an interesting link about up-coming x accessibility:
http://blogs.sun.com/roller/comments/korn/Weblog/european_summer_tour_2004_part
Speaking of other Unix-likes, Apple is including a screen readre as part of
the OS, which I'm beta testing. It's pretty good overall. Loads better than
Narrator for instance but not as flexible or customizable as say Jaws or
Supernova. Also it doesn't currently read the terminal unfortunately, and
has no way of accessing Classic apps.
XMMS doesn't use GTK, so it isn't accessible.
Not even the dialogs? Regarding Winamp, most screen readers are able to read
some of those bitmap controls on the player by interpreting the tooltips.
However, Winamp is fully keyboard accessible so no probs there. The
preferences dialogs use garden-variety Windows controls as far as I can tell
but they've still got some annoying problems regarding the tab order,
though.
someone writes a GTK2 interface for it, it won't be usable.
Could this work as a plug-in, replacing the native GUI?
Do any of those console players support plug-ins? On the Windows side, I
like the fact that I can play: mod, wav, mid, mp3, ogg, nsf, sid, spc, gym
and a variety of other formats including videos through one uniform
interface, namely Winamp 2.x, without having to add the overhead of yet
another player for each format supported.
-modify your Windows/Linux settings by default without asking or
telling you anything
These shouldn't be problems with Linux screen readers. Linux really
supports multiple users.
The problem is not multi-user support, it is that some screen readers, when
they are running, change some things like your keyboard repeat rate to
something else without asking you anything, namely Jaws. It's true it can be
turned off and it also returns your settings to the original if you quit
Jaws, but this kind of automation can be irritating nevertheless.
I prefered Window-eyes because it gave me a more realistic idea of the
apps display.
The same with Supernova Vs Jaws. Jaws still auto-focuses the first item in
the Start menu, when the truth is that to the non-screen reader users, when
you open up the Start menu no item is selected. This is Windows's fault and
something screen readres should not be changing. I hope we can relate this
to Gnopernicus at some level. Here I'm talking about automation I would not
want to see on the Linux side. But the trouble is I've been using WIndows
and it's screen reader products so long that most analogies and examples
come fron there, sory. By the way, do you know if GNOME or KDE automatically
selects the top-most menu item in the K or Gnome menus?
Another classic is link ndisplay. Supernova 4.x didn't even announce links
as the sighted don't have the word link on a Web page anyway. In stead, you
had to find out what things were links by yourself by tabbing around or
letting Supernova announce font style or color changes.
the accessibility is built into the libs used to create the controls.
The same thing with OS X (Panther). Stil, I wonder if any benefits could be
gained by including some kind of a screen interceptor driver on the LInux
side. I guess it could even run in kernel mode. Howabout hooking to some
font server to get everything that's rendered with a font of some kind,
automatically accessible to a screen reader. Would this work?
Gnome developers intend for all apps to
be usable from the keyboard.
Are there still some problems regarding keyboard usage? One thing that is
problematic in many Windows apps is that people forget some key element out
of the tab ordre, effectively rendering the given control keyboard
inaccessible without using some kind of a review mode.
Also, one thing that should have keyboard support in GTK, but hasn't got any
in Windows at least, is a multi-column list box. There's no keyboard way of
resizing, reordering and sorting by a given column, although these things
should definitely be supported. Well, most smart apps mirror the sorting and
even the order and resize facilities in some menu or dialog (namely Outlook
Express). Of course there ar apps in which the author has forgotten to do
this, though.
In addition, I was told Mozilla let's you actually use a physical cursor on
the page with some keyboard shortcut, even though there's no menu equivalent
yet. Does anyone know what this shortcut might be?
I wonder if the same thing could work in the console too. In stead of using
flat review mode, make it track the cursor and mod the console so that the
cursor may be freely moved around the screen with say alt+arrows.
On a side note:
On the Windows side, most screen readers I've tried, have adopted the
convention that when cursoring right in a text box, it reads the thing (word
or letter) that follows the physical cursor in staed of the thing that the
cursor just passed. Put another way, it reads the next thing right of cursor
in stead of the previous thing left of cursor if moving forwards. If moving
backwords, however, it reads the word right of cursor.
Now, on the screen reader beta on the Mac side, they've inverted this
convention. Though there's no logical reason why this couldn't be the other
way round, it is just so darn irritating when things work differently than
you expect. I mean it, I've been using Windows screen readres for something
like 6 years now and have gotten so used to the right of cursor convention
that this is a real problem for me. I've already complained to Apple about
it.
Perhaps a litle example wil clarify things.
say I have a sentence that goes this is a test and I'm cursoring it right
word by word (ctrl+right in Windows, command+right on the Mac, dunno about
Gnome though probably ctrl+right).
When I hear the word test on the Windows side, I'm assuming the cursor is
between a and test and can safely press ctrl+backspace to delete, "a", (the
previous word). Now on the Mac, hearing the word test would mean the cursor
is after the word test and pressing command+backspace would delete the word
test, in stead of the word, "a", as I thought it would. THen I'd have to
manually retype test, cursor left one word and retry ctrl+backspace to
actually delete the word a. This has happned to me countless times already.
What's the convention in Gnopernicus: does it read the next word or letter
right of cursor like in Windows or the previous one like in OS X?
automatically reads the contents of the text control.
very good. THis kind of sensible automation is all right to me. As is
reading IRC messages automatically when they appear. However, you should be
able to turn off or override this behavior at will.
write the equivalent modules for Win32 and Orca would work in that OSS
A good point. And isn't Python an interpreted language so it should be
fairly portable?
Your speech output module would use MSAPI,
Probably SAPI 5.
something that provided the screen data to Orca in the same data
structures.
Perhaps through MSAA with some mapping. I'm really new to Windos so can't
help much at the moment. But I'm learning. I ought to be writing a little
essay on accessibility in the Win32 API. It must be in Finnish, though, as
this is for a University course.
harder to writhe the Windows modules, but it should be possible.
Yes. Dolphin, the makers of Supernova, offer a free app called the
Synthesizer access manager (SAM). Despite the name it also manages braille
displayes under Windows and has got excellent support. THe app is free as I
said and the interface is public so SAM could be used on the Windows side,
at least as a temporary solution.
distracting to hear both screen readers talking.
Kkow what you mean. Having tried to use mIRC with Dolphin's Supernova and
Orpheus to read my input editing and MIcrosoft's SAPI 4 to read the channel
text at the same time.
It's hard for me to say for sure.
Well, then we can assume the overhead of using Python isn't critical at
least <smiley>.
Topic query:
Is this kind of generic accessibility talk all right here or should the list
be used strictly for Debian specific stuff? Put another way, are we better
off continuing this on a X or Gnome accessibility list if there's such a
thing? I'm interested, don't get me wrong, just thought some other list
might be closer on topic.
--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and more:
http://www.student.oulu.fi/~vtatila
Reply to: