Re: [orca-list] miscellaneous Orca comments

[Jason White <jason jasonjgw net>]

On Sun, Mar 09, 2008 at 11:04:42PM -0700, David Csercsics wrote:
 
> Yeah, you can certainly do that though it is not as usable as vim as far
> as functionality is concerned. I find that vim has a much better interface
> for a lot of things especially when it comes to coding. I can't find a
> nice equivalent for a lot of the vim functionality in gedit like folds,
> for example. Or the % keystroke. There are a bunch of other nice features
> that vim has that I like as well. So while you can certainly use gedit
> it is less efficient and I'm really not up for using an inferior text
> editor when the other should work. 

Emacs and Vi (the latter in the form of Vim, which really is an improvement as
the name says) are still the two leading text editors for Linux and Unix
systems. What can be accomplished quickly and efficiently from the keyboard in
those editors makes them a pleasure to use.

For the last decade I have worked entirely from the Linux console and within
Emacs using Emacspeak. BRLTTY provides a wonderful interface at the console
level as well.

The traditional use of desktops under X has been as a means of running
multiple terminal sessions. For people who want to do this, while switching
seamlessly between terminals and applications such as Firefox, Pidgin or OO.O,
I think the gnome-terminal experience needs improvement as you suggest.

Also, the ability to move the review cursor to the current item (e.g.,
character in the terminal) that has focus after using flat review mode is
important, an issue that I raised earlier in this thread and about which I'll
lodge a bug if it turns out that there isn't a satisfactory solution
available.

> The gnome terminal access should be a
> bit better than it is. I don't know how to fix most things because it's
> not obvious to me what is broken but I'd be happy to help work on it if
> somebody wants to help figure out where the problems are. 

Has anyone posted an Orca/Gnome accessibility debugging guide? The whole
system (X11, window manager, Gnome desktop and Orca) is highly multi-layered
and complex. Knowing enough to obtain debugging information so as to pinpoint
the cause of a problem and issue a proper bug report would certainly help.

My knowledge of C is much better than my knowledge of Python, but I'm willing
to learn more as time permits, particularly as Python appears to be a good
language in which to write scripts.

In general, I think Gnome Accessibility and Orca have taken the correct
approach of pervasively implementing an accessibility API, instead of trying
to build off-screen models based on incomplete or potentially inaccurate
information. The challenge is that every application that deploys standard
user interface components provided by GTK+ (or soon, we hope, QT) must
implement them correctly for access to be possible. Every application that
includes its own user interface components has to implement the accessibility
API in these components. Unfortunately, if the accessibility breaks, the
graphical interface often doesn't, leading to numerous "accessibility bugs"
that have to be chased down and fixed.

My worry is that we'll have an endless cycle of these accessibility bugs in
components of the desktop and applications, precisely because the
accessibility support is using semantics that aren't relied upon in the
construction of the graphical interface. Automated testing should be very
helpful in reducing regressions. Ultimately, though, I think the next user
interface technology needs to be one that works at a higher semantic level
while still allowing the "style" of the interface to be customized. To some
extent, the Web is evolving in that direction. I know that Gnome developers
are already able to construct some user interfaces from XML-based
descriptions, and further advances in this direction should make it easier to
validate accessibility support when the interface is created.