[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
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:


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:

Reply to: