Ubuntu-accessibility Digest, Vol 54, Issue 23

[Kenny Hitt]

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