miscellaneous Orca comments

Hello Orca enthusiasts,

I have just managed to get Orca running reasonably reliably
under the latest
Debian Sid distribution, using BRLTTY for braille and eSpeak
as the speech
synthesizer. I have tried Orca before, but this time I am
more serious as I
plan to take advantage of the excellent accessibility
available in Firefox 3.
Apparently, Debian packages are on the way, which will be
even better.

First my background: I have been using Linux since 1998, and
Unix systems
since 1993. Linux is my only operating system and I haven't
used either
Microsoft Windows or MacOS. Yes, I'm in the "never used
MS-Windows" category
and wish to remain that way.

The keyboard navigation sections of the Gnome accessibility
guide are highly
useful and informative. I recommend this documentation to
other new users. I
think it is important to be aware at all times of the type
of object that has
focus, as this crucially affects the key bindings which are
available as well
as their consequences.

I couldn't find documentation of the braille navigation
support, specifically,
which BRLTTY commands are recognized in Orca. The
next/previous window
commands of the braille display operate as expected; the
previous and next
line commands are bound, according to learn mode, to the
word above and below
the cursor, respectively. These are both flat review
commands. There seem to
be inconsistencies in what is displayed if these commands
are issued
repeatedly on the braille display, however, and I think the
braille support
would benefit from more work, more documentation, or both.

I can't find any flat review command to return the review
cursor to the
current object that has focus. Of course, this will happen
if the focus is
changed, but it is often necessary to return to the focused
item without
moving the focus. Every screen reader I have used offers a
command to do this.
The need is well illustrated in Gnome terminal, where one
frequently wants to
return to the current line after reviewing the output of a
command. Is there a
way to achieve this result easily?

Also, if you run Vim as a Gnome application, the
accessibility is somewhat
lacking, for example there are problems and inconsistencies
in the speech
output of the text in the document as the cursor is moved
around the buffer.
Braille output is somewhat better. I couldn't find any way
to access the
status line, and presumably there are user interface
controls available as
well. I think this would benefit from improvement. Emacspeak
should run under
Gnome, although it would conflict with Orca's speech output
if the same sound
card and channel are used for both.

Obviously I will have other detailed comments in due course.
My initial
impressions are that the basics work well and that the
developers have built a
solid foundation for further improvements.

_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

A quick correction to my earlier remarks: Vim runs under the
Gnome terminal
reasonably well. However, if I jump to the first line of a
document, the
cursor seems to be lost: I need to be on the second
character of the line in
order to read it. This only appears to happen with the first
line of a
document.

Vim run under gnome-terminal is still the console version,
it turns out. If I
run gvim (the Gnome version), I am presented with an
"open" button that
doesn't respond to keyboard commands, including
<return>.

_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

On Sun, 9 Mar 2008, Jason White wrote:

> A quick correction to my earlier remarks: Vim runs
under the Gnome terminal
> reasonably well. However, if I jump to the first line
of a document, the
> cursor seems to be lost: I need to be on the second
character of the line in
> order to read it.

I have noticed the same thing.  I have also had the
experience you 
describe with gvim.  I'd suggest using gedit when in Gnome.
_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

On Sun, Mar 09, 2008 at 07:08:09AM -0500, Adam Myrow wrote:
 
> I have noticed the same thing.  I have also had the
experience you 
> describe with gvim.  I'd suggest using gedit when in
Gnome.

Which is a major step backward from Vim or Emacs.

I'll wait a few days and if there isn't further follow-up,
I'll lodge bug
reports for either or both of the above. The vim issue in
the terminal would
be an Orca/Gnome-terminal bug, correct?

At this rate, the Orca developers are going to be swamped by
bug reports.

_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

>I have noticed the same thing.  I have also had the
experience you 
>describe with gvim.  I'd suggest using gedit when in
Gnome.

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. 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.
Ideally I'd
like to use gnome terminal for my usual terminal work which
includes
things like text editing and email and the like without a
lot of
clunkiness. Gnome terminal has issues with scrolling text as
well. I
know what's going on but it is not obvious to me how to fix
the issues. I
can work around the existing problems with the terminal with
a bit of
effort but it should be fixed at some point to make things
that much
more usable.
_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

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.

_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

Hi Jason:

Many thanks for your comments!

> I couldn't find documentation of the braille navigation
support, specifically,
> which BRLTTY commands are recognized in Orca....I think
the braille support
> would benefit from more work, more documentation, or
both.

Agreed.  We have minimal support for BrlTTY commands right
now and would 
really like to improve this for GNOME 2.24.  With your
extensive 
experience with BrlTTY, it would be great to hear from you
which BrlTTY 
commands should be supported and what Orca should do when it
receives 
those commands.  I've opened a bug here:

http
://bugzilla.gnome.org/show_bug.cgi?id=521599

If you can add comments to that bug, it will help us track
what's needed 
and will also give you something to monitor the progress (as
well as add 
patches if you want to help with the implementation).

Thanks!

Will

_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

Jason White wrote:
> At this rate, the Orca developers are going to be
swamped by bug reports.

Don't worry about that.  We'd rather have known issues
logged in the 
bugzilla database rather than have them go unreported.  Over
time, we 
just prioritize and knock off bugs and features at a most
maddening 
pace.  

Will

_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

>I have noticed the same thing.  I have also had the
experience you 
>describe with gvim.  I'd suggest using gedit when in
Gnome.

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. 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.
Ideally I'd
like to use gnome terminal for my usual terminal work which
includes
things like text editing and email and the like without a
lot of
clunkiness. Gnome terminal has issues with scrolling text as
well. I
know what's going on but it is not obvious to me how to fix
the issues. I
can work around the existing problems with the terminal with
a bit of
effort but it should be fixed at some point to make things
that much
more usable.
_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca

Jason White writes:
> ... Emacspeak should run under
> Gnome, although it would conflict with Orca's speech
output if the same sound
> card and channel are used for both.


I believe orca supports emacspeak drivers, though I don't
know whether
that includes espeak.

Janina
_______________________________________________
Orca-list mailing list
Orca-listgnome.org
http
://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca
 for more information on Orca