Ubuntu-accessibility Digest, Vol 54, Issue 23

[Øyvind Lode]

I'm a blind Linux user as well.
I don't use GNOME and probably never will.
It's to slow (Orca is very slow).
I use the console with ease.
The commands is not a problem for me at all using both speech and Braille.
I'm a reasonable fast Braille reader so reading commands etc is no problem
for me.
I'm a quite fast touch typist as well he he.
So the command line is very accessible for a blind person.
Especially if he or she use a Braille display.

But I can understand the frustration for a person using text recognition to
input commands.


-----Original Message-----
From: ubuntu-accessibility-bounces at lists.ubuntu.com
[mailto:ubuntu-accessibility-bounces at lists.ubuntu.com] On Behalf Of Kenny
Hitt
Sent: 24. mai 2010 08:19
To: ubuntu-accessibility at lists.ubuntu.com
Subject: Re: Ubuntu-accessibility Digest, Vol 54, Issue 23

Hi.
On Sun, May 23, 2010 at 07:39:33PM -0400, Eric S. Johansson wrote:
> On 5/23/2010 12:40 PM, Kenny Hitt wrote:
> > On Sun, May 23, 2010 at 12:16:12PM -0400, Eric S. Johansson wrote:
> >> On 5/23/2010 11:26 AM, Kenny Hitt wrote:
> >>
> >>> There isn't a kernel module in this case since they are using sane. I
> >>> regularly build and install kernel modules without needing to reboot.
> >>> Maybe these notes were for Windows?  That is the only explanation I
can
> >>> come up with to explain this.
> >>
> >> I went and read which reveals that is a Linux solution. I have observed
> >> that scanner interfaces are, fragile at best, and I'm not surprised
they
> >> want to reboot with the device turned on.
> >>
> > I just switched scanners yesterday with no need to reboot.  That idea
about
> > scanners doesn't match with my experience in Linux.
> 
> fair enough. I don't use scanners except for one and that's under Windows
> because I haven't had time to set up on my wife's machine. (Yes, her
Facebook
> workstation is the house linux box unless you count the mini ITX system
running
> virtual machines for my firewall and internal print services. Yes, let's
not
> count that :-)
> 
Setting up a scanner in Linux is easy.
1. plug the scanner into the computer and the power outlet.
2. install the sane package if it isn't already installed.
3. decide on what app you want to use for ocr and install if needed.
4. start using it.
Note none of these steps require a reboot of the system.

> > Since I'm totally blind, that means I'm likely supposed to be one of the
> > users of this product. Since I have years of Linux experience, I don't
have
> > much confidence in any app that tells me I need to reboot after
installing a
> > user space app.
> 
> really good point. And I'm glad to hear you talk about your experiences.
We need 
> more user stories to help extract a better than the current model for 
> accessibility. This is really great.
> 
> > I find I'm still faster and more productive in the text console at a
bash
> > prompt than I've ever been in a GUI like Gnome.  Gnome has never been
stable
> > or reliable enough for me to stick with it for more than a few months at
a
> > time. I had 4 years of Windows experience and was one of the early
adopters
> > of Gnome accessibility, but Gnome hasn't lived up to it's marketing.
> 
> right. That makes sense. What I'm hearing from your experience is that you
build 
> a mental model of all the commands, you can type them in and get feedback 
> through text-to-speech or a braille output device to confirm that you
entered 
> the right data. The unpronounceable nature of the commandline doesn't
bother 
> you??? Is that right?
> 
actually, I have a visual picture of a GUI desktop.  In Gnome, that isn't as
important as it was for
access to Windows.  In Windows, I had to use the screen reader's mouse
control to find objects.
The same concept isn't needed for Gnome.
In the console, there is no need to picture anything.  Think of command line
as a
conversation.  A screen reader will try to pronounce anything sent to the
synth, so
everything will have some word or phrase associated with it.  It might not
sound like English, but
it will be consistant as long as you use the same screen reader and synth.

> I think the big problem with putting accessibility features for blind
users on a 
> GUI is that you try to map a two-dimensional shallow but wide user
interface 
> into an aural format.  similar problem to what we deal with speech
recognition.
> >
Actually, that isn't my problem with Gnome.  My problem is lack of stability
and slow response.
My time in Gnome usually ends when Orca crashes and nothing I try can get it
to restart.  At that
point, anything in the Gnome session is lost.  My only option is to kill the
Xserver and clean
up the resulting mess in a console.
If Orca were a C program, I would just attach to the process with gdb in a
console and wait for the crash.
Then I would have a good backtrace to attach to a bug report.  I don't know
how to do the same with a Python app.  The debug methods I know about for
Orca create large files.
Since the crash can take a while to happen, letting Orca write large amounts
of data to a file isn't an option.

> >> The second way they fail is presentation. The name of the command, how
> >> it's invoked etc. it is not accessible either to speech recognition or
> >> text-to-speech. The last one, text-to-speech, may do a more credible
job
> >> at presenting garbled text (command names, commandline arguments etc.)
than
> >> speech recognition will when generating the same.
> >>
> > I don't follow this one.  help $command works for me with a screen
reader any
> > time I need a reminder of a built in command $command --help works when
I
> > need a reminder for an external command.
> 
> Okay. I was channeling from too deep inside my head on the theory behind 
> accessibility. Sorry about that
> 
> cp -al [UcWd]* .
> 
> How do you pronounce that? In simplest form, its
> 
The answer will depend on screen reader and synth.  With my current default
punctuation setting in speakup and espeak,
it sounds like:

c p al up w d

Notice I only hear the punctuation and case of the command if I review the
screen.  This behavior is my default by choice.
I could set punctuation to a higher value and hear more, but I only do that
when reading code and not mail.
In this case, espeak doesn't get the command right since I heard u p w d
instead of the actual u c w d.
When I reviewed the screen, I saw the correct command.

> Charlie papa space minus sign space left bracket cap uniform charlie cap
whiskey 
> delta close bracket no space asterisk space dot
> 
> ugly as hell and rife with potential for speech recognition errors which
makes 
> it even harder to speak!
> 
According to the posts I've seen about VEDICS Speech Assistant this problem
will be less with there solution.  It
can recognize commands that aren't English.

> If I was to make a little smarter using some macro capability it might be 
> something like:
> 
> Copy with links source pattern cap uniform charlie cap whiskey delta
> close with wildcard
> destination there (memorized target location)
> 
> little more verbose but, far more resilient against speech recognition
errors. 
> It's also form one could translate command into for a text-to-speech user.
The 
> downside with this model is that you need to create special macros for
every 
> stupid command and work out the appropriate argument handling grammar.
> 
Actually, your example would be way to verbos for text to speech.  I would
prefer something like
c p dash a l bracket u c w d right bracket star dot

The u w d would be at a higher pitch to show they are caps, while the rest
would be at normal pitch to show they
are lower case.  Since I already know what star and dot mean in Unix, no
need to say that.

          Kenny

-- 
Ubuntu-accessibility mailing list
Ubuntu-accessibility at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility