Using graphical interfaces as a blind user, and a little wish (Re: pulseaudio and speech: performance issues)

[Klaus Knopper]

On Fri, Jan 08, 2010 at 10:16:32AM +1100, Tim Cross wrote:
> 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.

I have heared this many times before, so I am curious: Are you content
with this situation? Why not create new user interfaces specifically for
non-sighted users instead of adding "workarounds for a minority" in
graphical programs? OpenOffice is Open Source, and I think it's not too
hard to add a non-graohical mode, or just use its libaries to support a
textmode ODT editor. Developing open source software for a "minority" is
not more expensive than buying licenses for special proprietary tools.

> 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.

Adding: Therefore, in open source, we don't depend on high number of
sales, but on interested-enough individuals who contribute by coding or
testing, or supporting development. And still, the money spent on
proprietary systems could be spent on accessible OSS system development
instead, instead of just waiting for someone else to solve the problem
for free.

> While we could hope that ethical/moral and legislative motivators
> able to do the same things with software than others can do.

But "hope" is not enough. I believe that it is the right of everyone to
get a system that he/she is able to handle, from all official resources.
In germany, for example, we have a law that forces officials to provide
barrier free information technology to all citizens (BGG ?11). It is a
right to get provided with barrier-free content, not a privilege one has
to pay extra money for. 

> 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. 

If we only keep "hoping", and we are not frequently picking on officials
and asking vendors specifically for accessible software, things will not
change. When visiting expos, I often sincerely apologize for not being
able to buy a product for my institution, because our company guidelines
forbid us to buy software that isn't accessible (AND working unter Linux).
Sometimes, I get a nice reply by mail a week later stating that that our
demands WILL be addressed in future versions. And some even seem to be
honest when writing that, because they have seriously lost customers
because of their software not following the rules. ;-)

> 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.

Or the third approach, which is more the Open Source way: Provide a kit
of working options for both approaches, let the user decide what he/she
needs, and build a customized system for him. In the long term, this
does not cost more money than licenses for proprietary systems.

> 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. 

Ok, maybe my thinking is too user-centric. I favour efficiency for the
user over easy maintainability. In my way of thinking, if a system is
more efficient for the users possibility, it is worth the extra effort of
development.

> 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.

Contra: Different Windows-versions and versions of Word / Excel /
proprietary collaboration software are also not interchangeable. It is a
fiction that users using the same system would be able to help each
other. I know few people who can help beyong "reinstallation" of you
have a Windows-based problem.

Interaction with the rest of the world is only possible through real
standards and standard protocols. If your browser speaks http, you can
access webpages. If your document processor only supports one single,
proprietary document format, you are cut-off from the rest of the world,
no matter how accessible it is.

> * 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.

Does this not counterdict what you said before about "integration"?
Since there are an endless variety of programs both propritary and open
source, a common standard in the user interface is also unlikely to
happen anytime soon. So why not accept the fact that there are different
programe who can do the same job, and decide on your own which one works
best for you?

Of course I can agree to the fact you stated, that many employers THINK
that it is best for every employee to use the same software, but in my
opinion, it is a big waste of potential and efficiency to force someone
to work with software with an inefficient user interface. If you can do
the same task with one software in 4 ours, but only need one with a
different software, this should be a more convincing argument.
Unfortunately, mand employers just are not ready to take hints from
their employees, it needs a paid-for consultant to convince them.
Welcome to Dilberts world. ;-)

> 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. 

It does not mean that there is a software problem. It means, in my
opinion, that your employer missed to see your efficiency and potential
that you WOULD have had when using different software, possibly working
on a different field where you could even exceed results of your seeing
co-workers.

> * Second class citizens. Like it or not, new developments in
> technology are rarely going to provide the necessary level of
> accessibility initially.

True. But whose fault is this? I don't think that making a user
interface accessible is additional work anymore, especially concerning
GTK2-based programs. Most GUI libaries already support ATK, DBUS or
others. The main problem seems to be that accessibility is missing from
the job description for programmers, because there are not enough voices
that remind the payer to make sure there is a small mentioning of
accessibility for the new software at no extra cost.

> 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

There is no need to have a GUI as well as a text-only version of the
same program, as long as there are programs who can just produce the
same results, and you can chose which one is best for you.

> 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. 

This sounds a little frustrated, could that be?

> * Applications with text oriented interfaces are typically less
> feature rich than their GUI counterparts.

I totally disagree here. The best system administration and programming
tool I have met that far is the bash (as someone else on this list
pointed out already), which has no graphical match yet. Also some
text-based processors like TeX have not been matched in quality and
flexibility yet in the GUI world. I think that, concerning results,
textual interfaces are still the quickest way to get a job done compared
with graphical ones, except for graphical tasks such as drawing a
picture, layouting etc.. Also, textbased tools have a lot more
combination possibilities and options than their grahical pendants.  And
I hear this statement from many others, who are younger than I am, too.
;-)

> 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. 

Question back: How USEFUL do you think is Javascript beyond graphical
applications, what can be done with Javascript that can't be done
without? Websites that rely on active Javascript for form-checking or
similar, are often broken and keep users away from the site because each
browser has its own set of Javascript errors. On my own website, I
needed not less than 4 browser-specific versions of a function that just
displays tooltips - which should have been done by HTML descriptions in
the first place, had they been existing when I setup the site. Each
browser version of Internet Explorer has its own defects in locating the
mouse position in the browser window, for example. If creating a
commercial website as contract work, I would never sell something that
requires Javascript.

I have seen many formerly frames and javascript-based websites being
replaced by single-frame and non-javascript versions recently.
Apparently, Javascript is not only a problem for text browsers, but
people buy less stuff on webshops if there is a one-time failure of the
website due to a javascript error.

> * 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.

Why is this? Should programmers be not skilled in some accessibility,
too? It's not necessarily extra effort.

> 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. 

The adriane audio desktop is just shell scripts with an ncurses dialog
menu. No matter how many programs we add later, the menu system will
still work years from now, and features to the menu can be added by
adding more bash scripts. It's easily extensible, and uses standard
mechanisms that are not likely to change in the future. Since our
approach is NOT the "one interface for all", switching to and
integrating with graphical desktops with orca, or to a totally different
desktop that is maybe joystick-navigated or by means of gestures and
cameras, is also possible. So, I'm pretty confident that it will not go
away just because of a new kernel or speechd release. :-)

As for elinks, again, I see a lot of possible improvements concerning
metatags and general navigation, but as of now, it's still the fastest
browser with sufficient features for me. I do occasionally also use
firefox, though.

> While a lot of the above may sound very negative,

Actually, for me, it didn't sound negative. You addressed the same
problems that users reported, why they cannot use (or are not allowed
to, at work) the software they prefer.

> 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. 

Great case, but if there was no accessibility in mind of your employers
buing decision, it could have easily resulted in getting
touchscreen-only devices that are impossible to use for a blind user
when there is no immediate TTS support in them. 

> 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. 

As a summary, we could say that there is a LOT of accessibility in Open
Source already, and toolkits for new programs are available, so there is
no reason anymore to claim thatOopen Source accessibility requires
"extra work". Which may be an advantage opposed to proprietary systems,
which may have better-sounding voice files, but restricted use cases.

Sorry, now my reply also got longer than planned.

Regards
-Klaus Knopper