Re: X Accessibility (Was: Gnopernicus ...)
On Tue, Aug 24, 2004 at 02:13:28PM +0300, Veli-Pekka Tatila wrote:
> Kenny Hitt wrote:
> >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?
>
Yes, apps that use GTK1 aren't accessible. Most, but not all GTK2 apps
are accessible. There were major changes from GTK1 to GTK2, so programs
have to be rewritten to use GTK2.
> 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?
>
Don't know for sure, but I think QT apps would have to be rewritten to
use GTK2 before they would be accessible.
> 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
>
That link is an example of a big problem with Gnome accessibility. From
reading it, you get the idea Mozilla is accessible. The problem is I
can't get close to the access discribed in that article. No one I know
on the Mozilla or Gnome accessibility lists can either. The Gnome
accessibility developers don't act like other open source developers
I've worked with. It's as if they are commercial developers claiming
to be open source. Users who want to help are mostly cut out of the loop.
I found out more about Gnome from that web site than I've learned from
almost 1.5 years on the gnome-accessibility-list and the
gnome-accessibility-devel lists. Of course, since I can't duplicate
access to Mozilla, I don't know how much to believe.
This situation has pissed off my blind friends who use Linux. They've
all given up on Gnopernicus and Gnome accessibility. We're all long
time console users, so our main interest in Gnome is Mozilla. Only 1
console browser can handle Javascript, and it has several other problems
that make it not a solution for web access. Some of my Linux friends
are trying to add Javascript support to an existing browser, some have
bought Freedombox, and some use IE when they need to use a site that
can't be accessed with lynx, links2.1, elinks, or w3m. I bug my sighted
girl friend to just use her Mozilla and read the problem sites to me.
> 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.
>
Apple is taking the same approach as Gnome. They are building
accessibility into the libs. Apps that aren't accessible will probably
have to be rewritten to use the new libs to make them accessible.
> >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.
>
Nope, the only info I get from a XMMS window is it's title. That info
comes from the Window manager and not the app. Someone will have to
write a GTK2 front end to XMMS before it will be accessible. I know it
should be possible to write since I've seen a console interface for
XMMS.
> >someone writes a GTK2 interface for it, it won't be usable.
> Could this work as a plug-in, replacing the native GUI?
>
Yes.
> 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.
>
Alsaplayer and zinf support plugins. Mplayer uses something like plugins,
but they don't call them that.
>
> >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?
>
>
Gnome gives focus the the first item in the menu. It isn't a screen
reader behavior, just the way Gnome does it. I don't have any access to
KDE. I don't have it installed on my systems. GUI users are stuck with
Gnome.
> >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?
>
Not likely. Windows screen readers hook into the video driver to get a
lot of their info. The equivalent in Linux is the X server. You would
have to hook into every X server to make something like that work. All
you would end up with if graphics data. You would need other programs
to try to guess what the data means. I think the same is true for the
font server. It just provides the graphics info to display the font
requested.
The programs that make up the GUI in Linux are user programs. The
kernel has very little to do with the GUI. The kernel helps X servers
get access to the graphics hardware, but that's about it.
> >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.
>
You still find some problems, but most apps have keyboard shortcuts for
all options. Important shortcuts are consistant. Alt-c is always
cancel, and alt-o is ok.
>
> 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?
>
It's called carrot browsing mode. You use f7 to toggle it. It is the
only way I know to read text in Mozilla. Currently, it starts at the
bottom of the page instead of the top.
> 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.
>
Carrot browsing is built into Mozilla. It doesn't exist in Gnome apps.
Flat review is limited to reading lines. Carrot browsing seems to be
able to read across the line with left and right arrow, but the response
from Gnopernicus is confusing and not much use.
> 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.
>
>From your description, it sounds like Gnome follows the Apple
convention. If I start on the t of the line
This is a test
and press control right arrow, I hear "this". Control backspace would
delete the word This.
> >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?
>
Yes. The Learning Python book I'm starting with says Python will work
on MS Windows systems as well as Unix systems. Python is a good choice
because it is object oriented.
> 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.
>
>
I think we're still on topic for this list. If we get off topic, I'm
sure Mario will tell us.
Kenny
Reply to: