[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Using graphical interfaces as a blind user, and a little wish (Re: pulse
From: |
Klaus Knopper |
Subject: |
Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues) |
Date: |
Thu, 7 Jan 2010 15:45:50 +0100 |
Hello list,
On Thu, Jan 07, 2010 at 10:26:19AM +0200, A wrote:
> In fact I have always wondered why are blind people directed to
> graphical user interfaces... I see the benefit for blind people to
> have speech dispatcher working and use some of the available text
> interfaces that can leverage it. Probably I have ignored a use case
> like yours, Bill.
This raises an interesting topic that we [Knoppix developers] have been
researching on for a while during development of the ADRIANE audio
desktop for Knoppix. Maybe this should rather be discussed in a forum,
but since the topic came up, please let's just start right here and then
have the list maintainers kick us off to an "off topic"-list. :-)
A little background: ADRIANE is a text-based, flat menu system that is
focusing on blind computer beginners who have NO prior experience with
Windows or Linux, neither commandline nor graphical interfaces. The
general approach is to "conduct a task quickly with no in-depth
technical knowledge required", like "surfing the Web", instead of
"working the desktop in order to get to starting a specific program"
(which is then more or less doing the job that the user really wanted).
Using the ADRIANE desktop, getting to an internet page is a two-step
process:
1. Chosing "WWW"
2. Entering the address (or chosing from the bookmarks)
Navigating through web pages is very fast compared with firefox or IE
with speech output, since the navigation is link-based by using the
cursor keys. We use elinks for that, though the user may never [have to]
learn a product name to know what she/he is using for getting the task
done.
Doing a web-based task like shopping or online banking is very easy
with the textual interface (though displaying pictures or videos on the
framebuffer is also possible, for visual aid).
Now the strange thing: Virtually everyone who has tried the ADRIANE
audio desktop in courses or expos has clearly stated that it is the most
easiest to use interface he/she has seen yet, and less complex and
complicated than any graphical application interface. We asked "why are
you still using Windows (or a Linux desktop with orca) then?", and the
answers break always down to the following:
Top 1: "my employer requires everyone to use the same software."
Top 2: "because it is the standard."
Top 3: "because I HAVE to use <name of proprietary program in a specific
version>"
Top 4: "because all my friends use <name of proprietary graphical desktop>".
> But anyways I see a little value in replacing MS windows with another
> windows system + it is a very hard goal.
I think so, too. Actually, some vendors who have tested ADRIANE, asked
if we could change it in order to work with the SAME keystrokes and the
SAME procedures/steps as Windows with Jaws. But why should we create a
"Windows replacement that looks and feels the same as Windows"? We
originally wanted to establish something that's easier to use, and does
NOT require working with a desktop that has beed designed specifically
for "eye work".
The fact that OpenOffice works well with orca, does still not make it a
program yielding better results or accessibility than using a
non-graphical TeX editor, just as an example. The approach of "everyone
MUST use the same desktop, no matter what tricks or costs have to be
used" seems very wrong to me. Even in the graphical desktops, every user
has his/her own preferences and changes look & feel as well as core
functionality to match her/his needs.
> The blind one needs a rock
> solid synthesizer + a featurerich text interface that doesn't open new
> windows and shows arbitrary messages in various parts of the screen.
Exactly my point. The more "interactive" a graphical desktops gets by
just popping up dialogs at seemingly random timepoints, thus
interrupting the task the user planned, the more annoying and unusable
it gets. If a person has a rest of limited sight, it's surely acceptable
to work on a graphical desktop with high zoom factors in combination
with speech output (using the compiz-fusion focus-tracking zoom plugin,
in combination with orca, which we do in one subitem of ADRIANE). But
with no vision contact to the monitor, all the graphical "enhancements"
of a desktop become useless and even counterproductive.
So, the best approach of accessibility, in my opinion, is not deciding
in terms of "graphical desktop vs. text console", but to chose the
system individually that gets the job done best and with the least pain.
The base core functionality needed, which we can probably all agree on,
is a stable text-to-speech engine that accepts input from various
sources (which is what speechd is supposed to do), and a screenreader
that knows how to access the relevant information from an application.
And this is indeed the same concept for graphical and non-graphical
applications.
> All I see these general purpose screen readers do is get around the
> graphical user interface rather than working with it. As well the
> blind one has to do stupid things to get around the design of the
> graphical application.
> </uselessrant></offtopic>
I dont think this discussion is "useless off-topic". It's good to
occasionally remember whom we are developing software for, beyond
ourselves, and not only staying with tech-stuff talk. Even on a
technical list.
Ok, just to add a last technical point: I would be happy to see an
official release of speech-dispatcher in Debian soon that features Halim
Sahins libao AudioAoutput option that is already in the git. I have
tested it thoroughly, and found it works way more stable, fast and
reliable with ALSA than the alsa module currently present in all
officially released versions of speechd. We will use this as the default
audio output in ADRIANE in the next versions.
Regards
-Klaus Knopper
- pulseaudio and speech: performance issues, Lex, 2010/01/06
- pulseaudio and speech: performance issues, Bill Cox, 2010/01/06
- pulseaudio and speech: performance issues, A, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues),
Klaus Knopper <=
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Steve Holmes, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Halim Sahin, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), trev . saunders, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Halim Sahin, 2010/01/07
- SBL & speechd (Re: Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues)), Klaus Knopper, 2010/01/07
- SBL & speechd (Re: Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues)), trev . saunders, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Klaus Knopper, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Tim Cross, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Rob Hill, 2010/01/07
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Klaus Knopper, 2010/01/07