[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: |
Tim Cross |
Subject: |
Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues) |
Date: |
Fri, 8 Jan 2010 10:16:32 +1100 |
While I do agree that to some extent having to retro fit a GUI interface
designed primarily for sighted users does create a lot of complications for
providing an 'eyes free' environment, I'm not convinced there is any really
good alternative. This is not meant to under value the excellent work many
have done with implementing console based access or building access on top of
text based applications.
To some extent, like it or not, the majority of new software is designed
primarily for sighted users. Accessibility issues are often either overlooked
in the design or are a secondary consideration. While things have definitely
improved in the last 10 years and there is now a greater awareness of users
with extra needs and many libraries have facilities to support such needs, the
reality is that users requiring adaptive technology are in the minority.
Software development is a complex, expensive and resource hungary process. For
commercial software, accessibility issues frequently represent considerable
additional complexity and cost without additional revenue. In the open source
world, direction is often based on individuals 'scratching their own itch' and
we simply don't have enough blind/vi developers with that itch to ensure
adequate accessibility is factored into the development of many open source
systems. While we could hope that ethical/moral and legislative motivators
would ensure all software is implemented with accessibility as a central
design objective, this is unlikely to occur while doing so represents the
additional overheads it currently does. to some extent, ensuring software is
accessible is still too hard - there are too many different libraries,
and approaches as well as a still too low awareness and udnerstanding of the
issues. I think a big part of this is because to some extent, the area of
adaptive technology and accessibility is still somewhat immature - we really
don't yet know how to best make things accessible and we don't have consensus.
This is not a bad thing as it means we are still looking and trying. As our
understanding matures, the approaches should also mature and building such
support into new systems should become easier.
This leaves us with two approaches. Either we develop systems which attempt to
add accessibility on top of a system designed primarily for sighted users or
we develop a system that makes accessibility a priority. both approaches have
their own pros and cons, but in the long term, I suspect making existing
systems accessible rather than implementing a system which is specifically
designed for blind/vi users is more sustainable, even if that means an
environment that is less efficient for the blind/vi user. In reality, as
blind/vi users, we will probably have to use both approaches and be prepared
to switch as needed.
Issues which need to be considered include -
* Integration. As users, we need to be able to interact with the rest of the
world. Having a word processor that is really user friendly from a blind/vi
user's perspective is of reduced value if most of the other people we work
with are using MS Office. This is particularly relevant in a work
environment.
* Too many applications. Every time I've moved to a new employer, I've
encountered new software I've never heard of or used before. to do my job, I
must be able to access this software. As it is often quite specialised,
there is unlikely to be an alternative more accessible version. Worse is the
fact that I might be the only blind/vi user of that software in the world
and am unlikely to get the resources to make it accessible or be able to put
adequate pressure on the vendor etc.
* Second class citizens. Like it or not, new developments in technology are
rarely going to provide the necessary level of accessibility initially. If
we are lucky, once the requirements are pointed out, they are added quickly.
However, if we also require a separate accessible text oriented version, we
run the risk of always being in 'catch up' mode - second class citizens that
don't get access to the new technology for 5 or more years after the rest of
the world has adopted it.
* Applications with text oriented interfaces are typically less feature rich
than their GUI counterparts. While many of the features of a GUI oriented
application are irrelevant to blind/vi users, they often also have features
that are relevant. For example, how many text based web browsers also have
good javascript support.
* the maintenance of any environment represents a considerable resource
outlay. Currently, the limited rsources to maintain the various different
accessibility approaches tend to split the resources. A more consolidated
approach could result in faster progress, but of course, deciding on where
to consolidate is a difficult issue. I do wonder if efforts, such as the
ADRIANE audio desktop, will be able to sustain that effort in the long term.
While a lot of the above may sound very negative, I do think there are some
really interesting developments on the horizon that make me somewhat
optimistic. In particular, the growth in demand for smaller devices, such as
smart phones and the growth in the use of text-to-speech technology for
mainstream users is very interesting. As users demand increased mobility in
their technology, I suspect that interfaces will begin to move away from the
existing large screen desktop orientation. this will have obvious benefits for
blind/vi users. As an example, my current employer has recently replaced both
their PABX phone system and introduced multi-functioned devices to replace all
the printers, photocopiers and scanners they have. The PABX has bult-in
text-to-speech facilities to enable users to listen to their email over the
phone. the multi-functioned devices come with built-in OCR software so that
scanned documents can be turned into text. These are features that were not
introduced with accessibility as a main driver, but rather as features to
provide mainstream users with additional value. However, both are features
that are useful to blind/vi users for different reasons. As a result, we are
seeing improvements in OCR and text-to-speech technology that are beneficial
from an accessibility standpoint.
There are three main approaches to accessibility at present
1. Screen reader approach i.e. Orca
2. integrated Accessible Desktops i.e. ADRIANE Audio Desktop
3. Application specific i.e. Emacspeak, speechd
I think all of these are necessary and have an important role to play. Systems
like Orca are important as they give us access to the same applications our
collegues are using and provide the ability to integrate well with others.
ADRIAN is important because it provides both an envrionment which may be
easier for new users to learn and potentially an environment that is more
efficient, especially if integration is not a priority. Systems like emacspeak
and speechd are very important as they provide a good environment for
experimentation and, for those with the necessary technical knowledge, a
relatively low cost mechanism to get access to something that is not possible
with other solutions. For example, the work T.V. Raman has done with
integrating emacspeak with Firefox is very interesting - in fact, a lot of
what he has done with respect to web accessibility is very interesting.
For the Linux environment, projects such as speech-dispatcher are of critical
importance. Good quality, stable text-to-speech is critical to all of the
approaches. It is a fundamental requirement. One thing I do wish would happen
is an update of the IBM ViaVoice Outloud libraries for Linux. this is my
preferred TTS engine. I wish it was updated so that it no longer required the
old stdc++ libraries and was available in 64 bit versions. I've tried most of
the other TTS solutions available for Linux, but none of them have the clarity
(especially at high speech rates), responsiveness and features of Viavoice. I
found the software dectalk TTS to be pretty good, but somewhat unstable.
Espeak is pretty good, but lacks some features and most of the rest are
lacking in features, difficult to understand at high speech rates and not
responsive enough.
Tim
.
--
Tim Cross
tcross at rapttech.com.au
There are two types of people in IT - those who do not manage what they
understand and those who do not understand what they manage.
--
Tim Cross
tcross at rapttech.com.au
There are two types of people in IT - those who do not manage what they
understand and those who do not understand what they manage.
- pulseaudio and speech: performance issues, (continued)
- 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, 2010/01/07
- 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 <=
- 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
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Steve Holmes, 2010/01/08
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), A, 2010/01/08
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Tim Cross, 2010/01/08
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Klaus Knopper, 2010/01/08
- Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues), Tim Cross, 2010/01/08
- eSpeak Features, Jonathan Duddington, 2010/01/08