GNOME.org
 

Re: Mozilla - like JAWS or like Hal?

Hi Jacob,

You write:



At 08:01 AM 5/05/2004, Peter Korn wrote:


3. Now that we've started a good discussion about what is needed for good
   blind access to mozilla, perhaps we can start similar discussions about
   other aspects of the desktop.  Here are some questions to get that
   started (this further discussion shouldn't be cross-posted to
   <mozilla-accessibility mozilla org> of course...):
    a. What is good, and what can be improved, in Gnopernicus access to
       Nautilus and the actual desktop window itself?



Desktop access and nautilus, I find, work quite well. I particularly like
how, even in icon view, we get told the filetype based on its icon, which
even the best windows screen readers don't do. Something I've noticed, in
gnome-2.6's computer folder, when something is mounted, rather than saying
"mounted" or some such, it'll merely say the icon name twice. I do think
this should be fixed, since it was a bit confusing at first. I'd also like
to see, when drive icons appear on the desktop such as when they are
mounted, it would say "mounted drive icon" or something similar, rather
than just icon.
These are good feature requests, though some may be rather difficult to implement. Nontheless, please file them as RFEs in bugzilla.gnome.org for gnopernicus (though some of this may well be Nautilus RFEs). 


 > > >      b. Same question, but about Gnopernicus and
gaim? >
How about automatic reading of incoming messages, like window-eyes does
with MSN messenger? There should also be ways to read back through the
message window, as can be done in AIM for windows. The mesage auto-reading
feature should, of course, have a way to turn it off if one doesn't want
it.
I expect this cannot be accomplished without scripting. Nontheless, another good feature request. Please file it as an RFE in bugzilla.gnome.org. 


    c. Same question, but about Gnopernicus and StarOffice/OpenOffice.org?



Get rid of the "multi-line text" messages inside of the document windows.
For instance, I here "paragraph 1, multi-line text... paragraph 2,
multi-line text..." when all I really need to know is "paragraph 1,
paragraph 2" and things like that.
Hmmm... I thought this was fixed, but I see now it isn't. This output is controlled by the Presentation settings mode you have loaded (see Preferences->Presentation). See /usr/share/gnopernicus/presentation for the two XML files "default.xml" and "verbose.xml". 

> Enhance responsiveness when speaking in

openoffice/staroffice writer--speech interruptability in particular. This
can on occasion get to be a major problem especially in the menu bar.
While we're on the subject of the menu bar, let's not have it read the
entire bar when one presses F10. Rather, let's just make it say the
current item, like other GNOME applications. Also, in lists it'll say
something like "list 10 items" but the current item will not be read, one
must up or down arrow then return to the item to here what item you were
on, which is can be an annoyance. Finally, in the special symbols dialog,
we need accurate descriptions for these symbols. Most of them read simply
as "A umlaut" or "e circumflex" therefore it is quite difficult to insert
an accented letter--if anyone has an easy way to do this, please write me
privately.
At the risk of sounding like a broken record (or a screen reader without a working shut-up key doing a file listing of very similar files): please file an RFE (or bug, as appropriate) for these. In general, if a particular UI element works one way in general GNOME apps (and particularly a way you like), and another in StarOffice/OpenOffice.org and Java/Swing apps, the bug is probably in the java-access-bridge component; while if StarOffice/OpenOffice.org is the odd-app out, the bug is probably there (and should be filed with issuzilla.openoffice.org). 


    d. What do you think about the Gnopernicus features?  The Gnopernicus
       NumPad commands and layer concept?  Braille interface?



I think the layer concept is a good idea but the way it is implemented now
is clunky at best. In my opinion, there should be four layers: a mouse
layer, a speech control layer, a braille control layer, and a magnifier
control layer. The mouse layer should combine the functions of current
layer zero and layer five--that is, the ability to move between objects
and click the mouse.
The keypad layers are completely re-assignable. I encourage you to play with this! These settings are stored in the gconf database for Gnopernicus (.gconf/apps/gnopernicus). 

. Right now, we don't have a way to move the mouse from

object to object. I'd like to see a mouse movement and click feature
similar to the windows screen readers, since whether we like it or not,
not all programs will be fully keyboard accessible and there needs to be a
method for dealing with such programs. 

Good suggestion.  Please file it as an RFE...


While we're on that, a graphics
labeler would be nice, as well as application-specific graphic
dictionaries.
This is a much trickier proposition. You were commenting above how much you liked the icon information (and filetype information) you were getting from Nautilus. This is NOT because Gnopernicus has any special knowledge of these icons (as would have to be done in Windows). Rather, it is because Gnopernicus is using the GNOME accessibility architecture, and Nautilus is providing this information to Gnopernicus. To have Gnopernicus override may be a significant architectural change, and I'm not convinced of the value. Can you detail where you would want to use this? 

> Either combine flat review mode with the mouse movement,

enhance it so that it works properly, or get rid of it altogether. In its
current state, it's not useful anyway, with it switching back to
focus-tracking mode within a few seconds of activation.
This is a known problem that I believe was recently fixed. See bug #138391 at: http://bugzilla.gnome.org/show_bug.cgi?id=138391 

> And most important

of all, before anything else is done... STABILITY! There needs to be major
work in this area, gnopernicus should be stable before features get
implemented left and right. After all, if a program isn't stable, its
usefulness is diminished no matter how many cool features it has.
Broken record time again... Please document each crash or hang as best you can, try to make it reproducible, and then file a bug. We won't reach the stability we want until we ferret out all the problems, and we don't do that if they don't get reported.
Note too please that because Gnopernicus is getting information from applications through the supported accessibility architecture (and not through patching the operating system or graphics layers), a problem that appears to be Gnopernicus stability may in fact be a stability problem with the application Gnopernicus is interacting with that Gnopernicus is triggering (e.g. a problem we're working on right now with Gnopernicus and gnome-terminal, where the terminal app slows waaaaaay down). From the end-user point of view, it's a stability problem whereever it is occuring. But please be aware that it may not be a Gnopernicus error... 


As for braille, I can't seem to get gnopernicus and brltty to cooperate
anymore, so no comment on that.


What versions of everything are you using?


    e. What TTS engine(s) do you use with Gnoperncus?



I use DECTalk 5 almost exclusively, FreeTTS otherwise.


    f. What are the most important things you want to use with Gnopernicus
       but cannot use yet?



Distro-configuration tools like redhat-config-date, redhat-config-users,
etc. These interface to GTK ghrough python, and I'm not sure if they
interface to GTK1 or GTK2. GTK1 apps would be nice, if at all possible, as
there are still quite a few of those, including sound editors and media
players. Also, a good graphical web browser--I think, once mozilla gets
its accessibility stuff implemented that we'll have a fine browser there.
Good wordprocessor which, once openoffice works a bit better, we'll have
that. Good access to rhythmbox would be nice, currently the browser is a
bit buggy with gnopernicus at the very best. And how about programs based
on motif or similar, or just the plain x libraries? There's lots of
programs that still use that so as to not have any toolkit
incompatibilities--mostly commercial programs. Finally, how about the beep
media player--it's a GTK2 port of XMMS that'd be quite accessible if the
playlist editor window would read.
Gnopernicus functions differently from all other screen readers (except perhaps the forthcoming Apple Spoken Interface) in that it uses exclusive the accessibility programming interface in GNOME, implemented by GTK2, Java/Swing, StarOffice/OpenOffice.org, Mozilla, and Evolution. Backporting this to GTK1 would be a massive task, if not almost impossible. It would likewise be a massive task to do this with other X libraries, like Motif. It wouldn't make sense to do it with straight X protocol; there simply isn't enough there to describe with the accessibility interfaces (no buttons, check boxes, menus, etc.). On the other hand, there is a lot of good work coming out of KDE/Qt land, and KDE 4 is planned to this accessibility architecture; preview version by mid-year, shipping by the end of 2004.
As far as XMMS - that's an accessibility implementation bug in that app I believe (custom playlist editor widget). An excellent place to file a bug! 


Well, that's my $0.02 worth.
And worth every penny. Now please invest that for greater returns by using the bug databases. You can enter GNOME bugs and feature requests via the web interface at: 

  http://bugzilla.gnome.org/enter_bug.cgi

and specifically enter Gnopernicus bugs with:

  http://bugzilla.gnome.org/enter_bug.cgi?product=gnopernicus
You will need an account in order to do this. To aid our efforts at tracking these bugs, please add the 'accessibility' keyword to all bugs relating to accessibility (e.g. missing keyboard-navigation in an app, etc.), and also please add 'gnome-access-bugs basso sfbay sun com' to the CC- list, which will ensure everyone tracking GNOME accessibility bugs is notified automatically. Also, please read the HOWTO first, before entering any bugs/RFEs, at: 

  http://bugzilla.gnome.org/bug-HOWTO.html

Finally, Calum Benson maintains a list of open accessibility bugs at:

  http://www.gnome.org/~calum/access-bugs-openonly.html

and you should *always* check to see if a bug you've found is already noted.


You can enter OpenOffice.org bugs and feature requests via the web interface at:

  http://www.openoffice.org/issues/enter_bug.cgi
You will likewise need an account here. Documentation on the IssueZilla system is at: 

  http://www.openoffice.org/project_issues.html



Regards,

Peter Korn
(aka the broken record)
Sun Accessibility team
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]