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

[Klaus Knopper]

Hi Tim,

On Fri, Jan 08, 2010 at 07:34:26PM +1100, Tim Cross wrote:
> Klaus Knopper writes:
>  > On Fri, Jan 08, 2010 at 10:16:32AM +1100, Tim Cross wrote:
>  > > 
>  > > 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.
>  >
> 
> Starting in reverse order. I totally disagree that writing open source
> software for a minority is not more expensive than buying licenses for special
> proprietory tools. This assumes the time put into developing the open source
> software is free  and that we have an unlimited supply of such time/labour.

You totally misundertood my statement. I said that DEVELOPMENT of Open
Source software is not more expensive than USAGE LICENSES for
proprietary software. I did not say that OSS development is completely
free. The business model of proprietary software is getting paid
per-copy, the business model of OSS is being paid-per-development,
customizing or support. Paying proprietary licenses does not make the
sofgtware better, but paying for development, customizing or support
makes the software (o0r using it) more efficient and adds value.

> Teams of developers, many funded by companies like Sun, have spent thousands
> of hours developing Open Office over the last 10 years. Writing a functionally
> equivalent program designed for blind/vi users would also take years of
> development and thats assuming you have a team of developers willing to and
> able to work on it full time. 

I agree. I make my living by developing  and supporting open source on a
commercial base. Some projects are unpaid spare-time, but most are
regular jobs.

> As a developer, I earn around $60 per hour amd can work around 2,000 per year.
> I could buy a hell of a lot of licenses for the amount of money I'd earn in a
> year, but if I spent that much time developing a blind/vi office suite, I
> would have barely even scratched the surface. Meanwhile, those with the
> licenses for the proprietary solutions not only have access to multiple office
> suites, they also have access to lots of other applications. 

Please let me give an example in order to understand what dimensions  of
money we are talking about.

In 2004, health insurance supplied us (after some fighting over whether
we could just get a Linux system with a braille device instead, which
was denied) a proprietary system consisting of: Windows, OpenBook,
Finereader, Jaws and half a day of education by the manufacturer.
What the system is supposed to do, and it MUST not do anything else by
contract with the payer, is just readig texts from a $30 scanner.
Substracting the hardware including braille device which would have been
the same for Linux, the total cost of this proprietary system was $7000
with a single-user license, and a dongle that makes sure the software
can never be copied over to a differet computer.

What could YOU do for $7000 as an open source programmer? Surely
installing and customizing a Linux system as easy book reader, and an
entire day of education is possible. If you calculate with $60 per hour,
there are a lot of hours left for extras such as preconfigured internet
access, surfing the web, text processing, SMS management ans everything
your customer thinks is useful. The proprietary system is not doing
anything of this, because health insurance thinks that extra features
beyond text reading are "luxury".

Even further, the OSS system can be reused on different computers or for
different use cases, while the proprietary one is a per-user copy. What
health insurance pays for proprietary software is a big waste of money
in my opinion, that should rather be spent on open source development
and customization.

This was what I am referring to when saying that Open Sourtce
development is not more expensive than buying proprietary licenses.

> It is very important to realise that software development is a complex and
> difficult task (there is a reason only about 10% of software projects succeed)
> and  its a mistake to assume because open source sofware is free that it comes
> at no cost. Open source software has the same costs for development as
> proprietary software. the economics are different because people choose to
> give up their time on the software and forsake personal income or free time.

I think we both totally agree on that OSS is a commercially viable
business model that gives good quality and support at a decent price,
and is not "you get what you get, for free".

> With respect to creating a blind/vi friendly text based interface for
> something like open office, I just don't think it is practicle. Firstly, it
> would be a non-trivial task that would take hundreds of developer hours to
> complete. Secondly, I'm not convinced it would even be possible.

I think it would be both possible as a vim plugin for ODT format, and
scripts for emacs. There are already XML plugins for most editors, and
an ODT file is basically a zip archive of XML and multimedia files. The
effort of writing a textmode editor for this may be much lower than you
think. I'm not talking of projecting OpenOffice to a textual interface,
I'm talking about a program that can produce the same results as
OpenOffice.

For a shell/commandline expert, this is already possible, but it's not
user-friendly for beginners.

> The nature of
> the application would likely mean that the interface and functionality of the
> system are tightly coupled. Unless it had a 'pluggable' interface API, the
> best you could hope for is to implement a text interface API that mimics the
> GUI interface code.

But I don't wat to mimic the interface. I want something that's easy to
use, while producing the same results and working with the same file
format. :-)

> However, its likely there are many aspects of a GUI
> interface that simply don't have a 1 to 1 matching with a text interface.

Again, an 1:1 match is NOT what we desire. Think of a task, or a result,
and imagine how to get there in the most eaasy and effective way, NOT
how you can copy the interface structure of an existing program.

> Even if you could, just writing the libraries to do this would be a large job.
> You would likely be limited to using the same language as the current
> applicaiton. If this is still Java, then you have even more work to do as
> there are very few text based interface libraries for Java. 

Actually, most parts of the JAVA api are completely GUI-independent,
except those used specifically for GUIs like AWT or Swing. If you browse
the OO sources, you will see that that the GUI part is rather small
compared with the rest of the libraries that handle file formats and
conversions. You could even replace buttons by a textual interface, but
that cannot be the goal.

> Even if all these issues are resolved, you still have hundreds of hours of
> development and your dealing with sofware that is still evolving and changing
> - a moving target if you like. The longer it takes you the more the base will
> have moved. 

I would have to do a precise calculation, but roughly estimate that
developing a textual interface to OO that can do exactly the same with
similar "layout" on the text console, will cost at least 100 programming
days. Comparing with proprietary software licenses that are spent in the
$100.000 range, this is cheap.

> On the other hand, I could put that time into developing Orca further. At the
> end of the day, I may still have an interface to Open Office that is
> sub-optimal, but at elast I have an interface, plus I potentially have
> interfaces to many other applications. 

If you manage to get complete control over the desktop, accessing every
button and function without a million hotkeys, and killing every
disturbing popup or loss of focus or confusion through parallel program
accesses to orca (maybe disabling the window manager completely and
running just one program at a time on one X display), you have reached
what we have in the textual interface right now. :-)

> Open source adaptive technology solutions have come a long way in the last 10
> years. When I first lost my sight in the mid 90s, the only solution that
> really worked and was available for Linux was emacspeak. There were a couple
> of very basic console text readers, but they were only very basic. The Speakup
> project existed, but wasn't really  ready for prime time use and there was
> only some toys/proof of concept stuff available for X windows. since then, we
> have seen Orca, speech-dispatcher, a more mature speakup and a number of open
> source TTS engines. The open source movement has done quite well and is
> continuing to improve. 

During that time, oralux using emacspeak was the first live CD that
supported blind users. Unfortunately, complete beginners were left alone
with a system that provides a great toolkit which can do basically
everything, yet has to be configured by an expert. Even today,
compairing a preconfigured proprietary system to a toolkit is plain
unfair. You can't expect everyone to configure everything by themselves
on a "free" system, where proprietary systems come preinstalled at a
high price. What we need to reach is that you can buy a computer system
based on OSS, preconfigured for your needs and capabilities, for the
same or even lower price that the same computer would cost with
proprietary licenses.

> some projects, such as Orca, have (at least in the past) recieved funding and
> commercial support in the form of developer resources. 

No doubt, orca is cool, and so is the GTK2 ATK which is used by orca in
order to access all GTK2-based prorams. Even LXDE works with orca even
that developers had not thought about accessibility in the first
release, just becauses it is linked with the right libraries. Sometimes,
accessibility is a no-effort task. Still, getting orca to work first so
that you get control over your system, not even talking about
integration of different voices or engines, is still an expert task,
which has been solved in specific distributione like vinux but yet has
to make it to the common computer sold at your nearest discounter.

> this should be
> encouraged and its unfortunate that many of the leading agencies don't
> recognise the benefits and possibilities that are there. In fact, I find it a
> constant frustration that these agencies, on the whole, appear to support only
> the commercial proprietary solutions. (In Australia, its even worse. The main
> organisation puts all their support behind Jaws and don't even support
> companies like GW Basic and window eyes, which has a far less restrictive and
> arcane licensing model than the license key model of Freddom scientific).

The way it usually works is: The government asks consultants about the
way to go for accessibility. These consultants usually come from
companies who sell proprietary software. And as long as VI organizations
don't raise their own voice and demand OSS solutions directly from the
government, which are freely available and everyone can use without
paying a high fee for "extras", it's going to stay that way of
governmental preference for proprietary software, sadly. The pressure
must come from the base, in my opinion, which are the "customers" who
are unsatisfied with the way they are being treated.

> At the same time, I think we also need to balance ideology with pragmatism.

Agreed.

> Blind/Vi users need a solution now, not at some vague future date. Many users
> struggle with the commercial systems, which on the whole, ffom a user
> perspective, tend to be more polished and easier to get going than most of the
> open source solutions.

That is because they come precoinfigured, paid by health insurance, with
education. We need the same NOW, for OSS solutions. Its not a matter of
superior technology, but a political problem.

> Many blind/vi users are not in a position to contribute
> to open source projects.

Actually, they are, because many programmers simply have no idea how to
design a GUI in a way that's appropriate for VI persons. We would need
someone sitting right besides us and telling us how it's easiest to
work with a program. The result can also be a more ergonomical graphical
interface, which is also added value for sighted people.

> Often, they are so very dependent on the working
> solution they have they are afraid to switch, especially to a solution that
> may not be as stable or one based on an operating system which is completely
> alien to them anf for which, getting hands on support can be very difficult.

Right, especially if someone threatens to take the system they have
learned to use for so many ways, no matter how complicated, away from
them, and now they are forced to learn something new, by issuing a new
version of their proprietary OS. Customers will do (and pay for)
ANYTHING in order to get that system back to the state they knew how to
use before. Getting longterm users of one working system to even TRY
something new, is very hard, because features of the old system are
always missed in the new one, and the new features which are possible
extending the users possibilities, simply "don't count" at that time.

> The largest section of the population who are blind and vision imparied tend
> to be older, often retired and often less technically confident than younger
> users. for them, issues of open source versus proprietary closed source is of
> little interest - they just want a solution and they want it now.

Or do they want the system that they knew how to use BEFORE they were
blind back, in an accessible way? Each users should use the system
he/she can work best with, in my opinion, I'm not a "Linux hardliner". I
just think that for beginners that have NO prior experience with operating
systems, working on a preconfigured OSS system for the first time is
easier than to learn the "Windows way" first in order to get a task
done.

> Ideology is important, but I think we also need to be a bit pragmatic. The
> most important thing we need to do is keep the issue alive - be in the face of
> the vendor and the employer. Don't go mekely - I may get chucked out, but you
> will hear it when I do! 

For our clients, ideology is not important at all, it is just the
decision which system firts your needs best and is the most comfortable
to you. When having to use specific Windows programs, the preferred base
is (probably) Windows rather than a Linux with windows emulation. If you
just want to surf the web, do email and chat, you are maybe better
off with a Linux-based system that is preconfigured with software that
does what you like.

> I like to think the best of my fellow beings, despite overwhelming evidence to
> the contrary. consequently, the lack of accessibility in many applications,
> both open source and closed, I think, is mainly due to ignorance. 

I would say "Missing awareness." It's not always their fault. ;-)

>  > > 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. 
>  >
> 
> Most developed economies have such laws. However, laws are open to
> interpretation. Consider all the efforts to specify what it means for a web
> page to be accessible. I've seen plenty of web sites who have put in a lot of
> effort to ensure their content is accessible and have gotten it wrong (hands
> up all those who are sick and tired of hearing "spacer" in web pages because
> the accessibility guidelines say that all images must have an "alt" tag. If
> its an image put in to make the layout look good, I don't care about it and
> don't want to hear it!

I have to smile here, because I have heared the same stuff here from
customers who ask "dows it have ALT tags?" while not even knowing what
ALT tags are an that they are not part of every software, but just an
element parameter in HTML. Similar for desriptive tags that HAVE to
explain every non-[native-language] word and that pop up tooltips
frequently which babble right into your browsers output. I really wonder
who makes these recommendations.

What I really miss are recommendations that say it must be possible to
use a webform with an text browser. THIS would be a good recommendation.
Luckily, most online banking pages and popular online shops have catched
up on accessibility during the past years, even without recommendations.
Maybe it helps to complain and tell "I cannot buy anything in your shop
because it is not accessible.". Here, a high number of complaints can
really change things.

> If a web page is accessible using Jaws/Window Eyes, but is not accessible
> using firefox/Orca or w3m or elinks, does that page meet the legislative
> requirements or not? 

My statement in court would be that the web page must be accessible with
the system that the user choses, which is HIS/HER decision, nit the
governments. The law states that essential functions of IT systems must
be accessible for everyone, and every "guideline" beyond this does not
have the same character as the law. So, arguing with a guideline that
"does not mention elinks" is weaker than pointing to the law that says
the system must be accessible to the user. The user cannot be forced to
use a specific OS by the government.

>  > 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. ;-)
>  > 
> 
> don't get over caught up in my use of the word hope.

I don't. Just have heared the word "hope" many times before, and it
usually means that nobody is actually DOING something about the problem.
I did not mean you. ;-)

> I would never suggest
> that s all we do. I meant that we would hope that an idividuals right to
> access regardless of any physical barrier, such as blindness, would be
> apparent to everyone and that such considerations would be part of the main
> design goal., not, as is too often the case, an after thought. We need to
> ensure that access for all is a standard requirement. 

Absolutely.

> At present, a big part of the problem is that its not clear to vendors exactly
> what they need to do to make an application accessible. I've come across
> plenty of applications that are accessible if you use Jaws/Window Eyes, but
> are not if you don't. I've come across applications where they have followed
> the guidelines or have built with available accessibility libraries that are
> still only marginally accessible or only accessible if you use specific
> technology etc. 

That is because [at least the] proprietary vendors see accessibility
still as a lucrative "add-on" which brings an extra income because of
laws that require to buy those "extras", while the law actually says
that software must already be designed with accessibility in mind (at
least for govermnental applications). But awareness of the difference
is low. Most employers and governmental agencies still associate
accessibility with extra costs, which may be true in terms of hardware,
but not in software if the design specification is well done.

>  > > 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.
>  > 
> 
> I don't see that as a third option. It is just both the two options I listed
> and as I said later in the email, we do need both.

Ok.

>  > > 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.
>  >
> 
> considering the user perspective is  of critical importance. there are far too
> many applications out there which have failed because at the end of the day,
> regardless of what the app did, if users don't like using it, they won't.

And they should not accept software they are not comfortable with, the
same way in OSS as in proprietary systems. But yet, I have not heared
someone complain because a proprietary system fails to work as expected,
because "that's just the only way the vendor sells this thing, and it
cannot be changed.".

> However, we need to balance things. There is no point in developing the
> ultimate application for blind/vi users if we don't have the resources to
> maintain that application. 

"Ultimate application" is idealistic, but I'm content if users feel good
when using the software, so I know it's "sufficiently accessible". There
is always room for improvement, otherwise a programmer's life would be
boring. ;-)

> The biggest cost of all software, both proprietary and open source is
> maintenance. This is the number one killer of applications. 
> I've seen many decisions made that I argued against because I thought they
> were a bad technical solution. I've later realised that while there was a
> better technical solution, the maintenance overheads that solution introduced
> would have killed the app. What is needed is balance.

Maintenance is the same for proprietary or non-proprietary systems, and
SHOULD be the highest cost factor in the total cost of operation (there
is no ownership for proprietars systems).  Maybe OSS is a little easier
to maintain because it can be changed and repaired easier, without
begging the vendor for help. For the expensive system mentioned at the
beginning, the investment for licenses was way higher than maintenance
and updates. The system is just expected to last for a few years in this
case, there are no "upgrades" or improvements foreseen. For OSS,
upgrades may be available more frequently, but this does not mean they
have to be done each time (if there is no security risk involved).

> In an ideal world, all the software would be just as accessible regardless of
> whether it is open source or proprietary.  In such a world, it would also be
> clear as to what "being accessible" means, which I don't believe is yet the
> case. Of course, in a perfect world, all software would also be open source
> and we would all have the knowledge to get the most out of the technology. In
> that world, we wold be able to concentrate our efforts and would undoubtably
> come out with  a better solution. 

I think there IS room for proprietary software, even in an ideal world.
As said before, each user should chose the license and software model
that's best for him/her. But it should not be a vendor or the government
which makes the choice for the user.

> Unfortunately, this world doesn't exist.

...yet.

> We have debate regarding what
> accessible means, we have limited funds and we have limited resources. What we
> need to do is make the best use of the available resources and continue to
> push the accessible agenda and educate everyone. We also need to keep
> experimenting and learning. 

Yes.

> Personally, I'm not fond of the approach which suggests creating separate
> envrionments that are specifically designed for blind/vi. This is partially
> because I don't think we have the resources to do it well and maintain it.

I think we do, because OSS is traditionally working for the individual,
not for the masses. And for the same budget that is spent for
proprietary software, we can do a lot more, since the "useage license"
will just be turned into a "customization, education  & support" fee.

> However, I also have a philosopical objection to it. 
> 
> To some extent, this is similar to the old idea of having special schools -
> what you could call a separatist  approach. This was the dominate mode of
> thinking when I was in school and I'm pleased thatt it now appears to have
> been replace with an integration approach. The separatist approach tends to
> result in isolated communities which fork off from the rest. In times of
> strong economic growth and funding is plentiful, these specialised communities
> tend to do well. They get all the latest equipment, specialised teaching and
> all work towards a common goal. However, when funding dries up, these
> communities turn into ghettos. Because they are separate from mainstream, they
> are easily ignored and worse yet, you have people who grow up in an artificial
> environment which is not a true reflection of the wider world, making
> adjustment and fitting into that wider world more difficult. 

Interesting thought, but that's not what I wanted. The opposite is the
case: Using the right tools, matching the users needs and capabilities,
you can AVOID "special treatment". Instead, you get back in control and
can handle the same amount of work and complexity, using your own tools,
as others can with their "common" tools.

Of course there are always some extras, like learning braille, which
require special classes, but this should remain a small part. We do also
have blind and deaf students at our university, which get along with
studies well, using the right tools and few extra help.

> A similar situation could occur if all our efforts were put into solutions
> that focused on software designed specifically for blind users. While we had
> lots of resources and funding, we could possibly develop some great user
> friendly applications that could provide excellent access. However, if things
> get tough and funding is not available, systems won't be maintained and
> eventually, as the rest of the world moves on, we are left behind. Worse yet,
> the rest of the world won't even see us or worry about it because they have
> not had to. 

Why "funding" when there is apparently so much money available for
regular development and support, when health insurance and government
spend incredible amounts of money for proprietary accessibility-related
software licenses that have to be renewed in every software update
cycle?

> A more integrated solution involves the accessibility layer on top of the
> existing applications. Blind users are part of the main user community and
> well integrated. Sofware developes/vendors are forced to consider developing
> their software with accessibility in mind and see blind/vi users as a normal
> part of their user community and possibly their potential customers etc.

Yes. These developers/vendors should become the majority, not only
because they are forced to, but because it's less investment to develop
accessible applications in the first run, than adding accessibility
later.

>  > > 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.
>  >
> 
> Except these are issues facing all users and not unique to blind/vi users. As
> such, more are affected and it is more likely a fix will be found. Sure, there
> can be version problems and OS problems etc. However, when these are
> addressed, I can still share my MS word document or spreadsheet with
> colleagues and collaborate with them in the working environment. 

Since I use OO for this, you can also share a word document with me,
though I would prefer to get the information into an international
standard format such as ODF or plain text / iso8859. But back to
availability of help: having a group of friends using the same software
is great. Organizing "free" self-support groups parallel to having
commercial support available is an essential point.

> Many larger organisations now adopt a standard operating environment to avoid

"standard" in which meaning?

> most of the problems you listed. If a blind user is unable to operate in that
> environment, many employers will not employ them. some would argue that many
> countries have legislation to prevent such discrimination. However, such
> legislation is only of marginal benefit. In reality, it just educates 
> organisations to be more careful regarding what they say. Instead of telling
> you you didn't get the job because you are blind or because you can't work in
> their standard environment, they will just tell you you didn't get it because
> you didn't have the skills they were after. 

This is sad, it tells that some employers see blind people as a burden
required-by-law instead of a valuable resource that does productive
work. Some lobbyism in the direction of activating potential that is
currently wasted because of inefficient software, would be good.

Why can employees not make recommendations in terms of "I could work
more efficient on this project if I could use THAT software instead of
the company standard."? Fear to get fired? This is a terrible situation,
and neither good for the employee, nor the company.
 
>  > > * 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?
>  >
> 
> No, it doesn't contradict my point. You are mixing up two levels of
> integration. The integration blind/vi users have with other users and the
> integration that all uses have. My points addressed the first. 

Ok, understood.

> the other point is that there isn't always an alternative application
> available. There are no alternatives, accessible or otherwise. Many
> organisations have purpose built in house applications. In fact, the greatest
> employer of software developers is in in-house development groups that write
> software that the rest of the world never sees. Other software domains exist
> where there is very little competition and alternatives are not available. For
> example, the three projects I worked on prior to my current project involved
> software that cost between $1.5m and $4m. If I want to work for that
> organisation, I need to be able to access the product they use, there is no
> alternative.

AFAIK, most inhouse enterprise software systems use a web-based
cooperative framework, which means that you have a browser-based client.
If there are browser extensions which only work in a single version of a
proprietary system, options are indeed limited, and the company is
caught in their own strategic decision. Still there are a few options
left:

- Extending or rewriting the cliet software for accessibility, which may
  become a requirement in the future,

- Create an environment for existing clients that make it more
  accessible.

Sometimes there is no alternative, and you have no choice. But if there
is a choice, we should take advantage of it.

>  > 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. ;-)
>  >
> 
> While I do agree there can be some of this, I think you over state it
> somewhat. In smaller businesses/organisations, such flexibility is usually
> quite straight-forward to achieve. However, in larger organisations, its more
> complex and much harder to make work reliably and efficiently. You also have
> the issue that people, on the whole, don't like change. Someone will want to
> continue to use what they are familiar with and will rationalise that choice
> in remarkable ways. In larger organisations, you often need to have multiple
> staff cover the same work. this becomes much harder if everyone is doing it
> 'their own way'. However, this is a wider issue that is not specific to the
> accessibility issue. 

Fear of change is a very common reason, and sometimes there are
unavoidable changes in the proprietary world as well. The proposed
switch to Windows Vista from XP when XP support runs out, was a good
reason for many companies to change to OSS-based systems instead. Once
that is accomplished, changes are more gradually and no bad surprises
when support from the only official vendor runs out.

>  > > 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.
>  > 
> However, you are now ignoring what I may have wanted. What if that is the area
> I want to work in?

If that is the area you want to work in, your employer should provide
you a system so that you can efficiently work in that area. I did not
disagree on that. Your employer should NOT enforce you to work in a
field that you DON'T like, just because that's the only ony where he
invested in accessibility.

> Am I to be prevented from that level of self determination
> simply because it involves specialised software and because we ahve put our
> resources into creating a special purpose blind users desktop, which by
> definition, will be general and not specific, I don't have that software.

No. Same as above.

> On the other hand, if we had put resources into developing adaptive technology
> which leveraged off existing applications, iether I would have access or at
> worst, would need to hassle the vendor to make the modificaitons necessary to
> enable the adaptive technology to work with it.

If the vendor says "No", or the price is inacceptable what are your
options?

>  > > * 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.
>  >
> Agreed. However, if blind users were to use an environment that is
> specifically designed and built for blind users, there will be even less
> pressure on mainstream developers to incorporate accessibility into their
> design and implementation. 

Depends. Many applications are client/server based, and the core
functionality lies in the server part. So, the presentation layer is
independent from the application. With this concept, the GUI part is
quite independent. As you may have noticed, many Linux-based
applications have a text-based frontend as well as a graphical GUI, some
even for different desktop systems, like networkmanager, linphone,
mplayer. This is usually not because of foresight of programmers for
accessibility, but because textbased applications are easier to script
and can be integrated in larger environments.

>  > > 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.
>  >
> but this was the original point of this thread. the question was whether we
> should be putting resources into making GUI programs accessible, despite the
> fact that this frequently results in a sub-optimal interface experience for
> the blind/vi user or should be be developing apps that have interfaces
> specifically designed for blind/vi users.

Right, back to the roots. My initial point was that I find it more
practical for a user to have an environment customized to match exactly
his/her needs, rather than making applications designed for graphical
use accessible. It does not mean to AVOIND making graphical applications
accessible, especially that users with low vision may still feel more
comfortable using the graohical desktop with high-scaled magnification
and speech as feedback. So, all options should be developed in parallel,
with interfaces in between. The point of disagreement was just if the
"one desktop for all" concept should be preferred over "different
desktops for the individual".

> My argument is that we must have
> both.

Absolutely. The "text-based", or rather "one-dimensional" desktop is not
dead or superseded by graphical ones. For each application, the choice
should be on you which environment works best for you.

> Only having applications specifically designed for blind/vi users will
> result in us being second class citizens in the technology world.

Not applications, the applications should be designed taylorable for
each users needs. The environment should be optimized instead, and the
applications must be made to fit into that environment.

> I've never
> suggested all one way or all the other. Both are required. My only real
> concern is that I don't believe a suite of blind/vi user specific software is
> maintainable in the long-term and that any effort put into that is effort not
> put into the alternative, which I think is more maintainable and would provide
> better overall results, even if the result is sub-optimal. A result is better
> than no result.
> 
> I will modify my standpoint somewhat based on som eclarification you provided
> below. I'm not familiar with the ADRIAN desktop, but was under the impression
> it was mainly applicaitons specifically written for blind/vi users.

Yes, it's focused on computer systems that don't require a monitor for
use. But as I got to know, it's also being used by sighted users because
some tasks are just quicker to do in ADRIANE than in the graphical
environment where you need a lot of mouseclicks to even "get there".

Parts of the utils programmes for Adriane, also work fine in the
graphical environment, for example the scanning and OCR tool and the SMS
manager can be used in the graphical environment with the mouse as well.

It's not as if we deliberately try to make software inaccessible for
sighted users, just because we created a textual menu system. :-)

> If I
> udnerstand you correctly, the system is really a collection of text based
> applications with scripts wrapped around them to provide a more integrated
> envrionment for the blind user. As such, maintenance may not be a huge issue,
> though I would be concerned about the maintenance of the text based
> applications it depends on. 

Why do you think so? There is a menu around (currently) elinks, mutt,
gnokii, irssi, ocropus/tesseract, mplayer, mc and a few others, also
startx for easily starting orca with a single application in fullscreen,
or starting LXDE with orca. It is completely modular, we can easily
exchange programs. The main point is that beginners don't have to know
how to type a command or work with the shell (though the option still
exists). I can not think of many things that can break. If elinks or
mutt cease to exist, we can use a different program-

> have you ever used emacspeak? To some extent, it sounds a little similar in
> the sense that emacs provides the 'glue' and the interface. It is by far my
> preferred environment, though this is partially because it is so customizable
> and because lisp (even elisp) is my preferred programming language. 

I never got around well with emacs becuse of the Meta...something
hotkeys, so I rather thought of how does one select functions from a
cellphone without looking at the display, and got the cursor keys,
f1...f10 and capslock (for speech and onscreen navigation functions) as
the main input keys which are easy to find on a keyboard. The system
greets you with a short help, so you can start exploring navigation and
programs on your own without needing sighted help. Of course muss and
elinks are way too complex to be documented this way, but the hotkeys
have been changed in order to get a similar look&feel in most programs,
and are easy to learn.

The ncurses-based menu system is based on dialog for textmode, and
Xdialog for graphical mode, but in graphical mode, you would rather use
the desktops menu instead of the adriane menu.

>  > > 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?
>  >
> 
> Not at all. Though, possibly somewhat unfortunate if you feel it needs to be
> brought down to personal issues. 

I have to think about how to interpret this. :-)
For me, my desktop of choice is always something "personal" (last but
not least, you usually personalize your desktop on first start).
But I don't take it personal if someone else does not like the software
I use. I would have a lot to worry about, otherwise. ;-)

>  > > * 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 I do agree that GUI functionality is often over stated, we need to be
> wary of judging things to harshly because of our own difficulties using GUI
> interfaces. I started in the industry when text interfaces were the norm. I
> dislike the mouse (now can't really use it), I prefer text and I pride myself
> in understanding and knowing how the technology I'm using really works.
> However, I preferred text interfaces even when I still had sight, so its not
> my blindness that has turned me off GUIs. 

I always used the shell whereever possible, and combinable text-based tools 
rather than GUI tools, simply because it is more efficient for me. Plus,
mutt can cope with my insane inbox better than and graphical MUA.
Yet, I find extensions like compiz-fusion intensely practical,
especially for presentations and small notebook displays. You just pick
the things you like from a great toolbox and combine them in a way that
makes you more comfortable, or let a supporter do this for you, if you
are an employer or commercial user.

> However, I've found from experience, that I'm the exception, not the norm,
> especially amongst younger users. We are now in the situation where the new
> generation of workers have grown up with the GUI. They find the test interface
> alien. They also dislike having to learn and know all these weird unix
> commands or odd things like awk, sed, sort grep etc. they don't want to write
> scripts, they want to enter values into a GUI dialgue and hit enter. They
> don't want to use adduser, they want to enter the information in a gui and hit
> OK. they, on the whole, don't care about what is really going on. 

In general I can agree to that observation. But it seems that GUI users
see the shell and text-based tools occasionally as the "professional"
way of working, which they don't have the patience to learn about, and
admire that the shell can do things in half the time they need to
accomplish the same job using mouseclicks. Why sould even microsoft
recently add commandline tools for system administration, if there was
no demand?  Sometimes students ask me to slow down when presenting a
task in the shell, just because they cannot catch up in time using the
mouse when, for example, compiling a java program, navigating through
data or similar. So, fancy GUIs may after all not be seen as the
ultimate solution, and we just need more informatics classes in using
the commandline to speed up development.

I THINK that the mouse could be used as an additional input device
without too much geometrical approach, for example for quickly browsing
through the text screen and "overview-reading". The mouse yet has to be
discovered as an addon to a blind-friendly screen interface. Maybe we
can do something with gpm and the speech-dispatcher.. Ok, this is
off-topic. ;-)

> Combine this with employers desire to reduce costs and the fact that those who
> really understand the technology, the low level way things work etc, tend to
> get paid more and what you get is a de-skilling and staff who are only capable
> of using the GUI interface. I don't agree with it, but I don't see it
> changing. 

Let's leave this as an unresolved issue. We cannot get users who are
afraid of technology, to learn about it by providing an interface that
requires higher skills. I prefer the shell as working environment, but
many use the computer just as a blacbox that is supposed to play music
and "do things" with the least possible effort. I know a lot of people
who prefer a remote control and a single-purpose elecgronic device over
the universal computer with a keyboard.

> However, this is aside form the fact that there are some GUI interfaces that
> do things better or provide functionality which is difficult or impossible to
> do in a text only interface. For example, a frequent question on the TEX lists
> is how can people working in groups able to get the same functionality as
> Word's track changes facility. The anser is usually to use something like diff
> or version control. However, in reality, this is nowhere near as usable as
> this feature in word and it is largely because of the GUI. Other examples are
> things like the use of GUI facilities to represent information which requires
> multiple words in text.

I recently stumbled over "vimdiff" for easily displaying and adopting
changes in the text console. Apart from the fact that vi is probably not
a beginner's editor (though it could be, using a nice preconfiguration),
this an example on how a textmode differential editor could work. Also,
why not preseting the history of a document as a menu or list, and let
the user chose the versions to compare or to work on? cvs or rcs are
just tools, the presentation layer can be designed in different ways.

I wonder if this not already exists somewhere in a package. It should be
quite easy to interface a text editor with a dialog gui and automatic
saving of differential files.

> Using this, you can express more information in a
> screen than you can with text.

The information you have on a graphical screen is still the same in a
textual representation, not talking of pictures here. There is no way
that you can display "more" information on a graphical screen than on a
text screen, just the type and layout of presentation is different.
Again, not talking about pictures here.

> Sure, we can use sound icons etc, to do this,

Or text icons...

> but it is still limited. However, it remains that there are situations where
> it is difficult, possibly imposible, to replicate in a text only interface,
> functionality available in a GUI interface that was almost trivial.

Example?

> In many of
> the cases, it may just require someone smarter than me to com eup with a good
> solution. Track changes is possibly a good example. I've found ways to work
> around this, but what I have is nowhere as functional or usable as it is
> implemented in Word. 

OpenOffice can do this as well, so the information must be present in
the underlying XML files and possible to read and display appropriately
with textbased editors as well. For the time being, we uae what's
avaible, of course.

>  > > 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 use to think that way, but have changed my opinion. There is a lot that can
> be done with javascript that creates a much richer and more user friendly
> interface for web applications. Its of little benefit to basic web pages, but
> for more complex web applications, its a huge benefit. I've seen some really
> remarkable applicaiton interfaces within web browsers that were simply not
> posible before javascript. 

Thinking of Ajax, this may be true, but again, the Javascript-extensions
in question are largely graphical/mouse-oriented, such as dragging and
dropping pictures in a photo album. So, developers of rich web
applications must make sure they don't require graphical interface
extensions that are not available to everyone.

In one of my projects, a graphical interface for teacher administering
students accounts is written with Javascript extensions that allow
easier grouping and assiciation of accounts. Yet, the interface must be
accessible with a simple text browser as well, which just leves out the
possiblity of doing stuff with the mouse, but still the basic function
is guaranteed.

> I do agree that javascript is often over used and used in irrelevant and
> msguided ways. I also think it is still a little immature, but expect it will
> improve. 

It's rather flaws in the browsers that prevent compatibility than
immatureness of Javascript itself, plus vendor-specific extensions.
I think that Javascript could even be used to enhance accessibility in
terms of hotkey support, but this is a rather seldom case that I have
only seen in an online banking application yet. Unfortunately, it did
not even work there, but it was a nice try. ;-)

>  > 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.
> 
> While I agree that javascript is often used inappropriately, the bottom line
> is I don't think it is going away any time soon. This means that if we want
> full access, we need browsers that have good reliable support for it and
> currently, I know of only one text browser with minimal javascript support. 

I'm afraid that plugin-based extensions like silverlight/moonlight or
air will be the next hyped technologies, and supersede javascript in the
long term. Chances are that the open sourced pendants have some degree
of accessibility built in when using the right toolkit.

> The work Raman has done with emacspeak in this area is quite interesting. For
> example, useing the Moxlab "repl" you can query the DOM and run javascript
> etc. Hooking this up with emacs, emacspeak and w3m, you can have an
> envrionment where firfox does all the heavy lifting for you and you then query
> firfox and have the bits you want rendered within w3m inside emacs, so you
> have the full speech support of emacspeak. It is still too fragile for prime
> time use, but does show the potential and alternative ways of making something
> accessible. 

A device-independent interface to XUL and the HTML rendering engine of
firefox would bne extremely interesting, not only for building
text-based guis.

>  > > * 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.
> 
> I never said developers shouldn't be ware of accessibility issues.

The question was meant more rhetorical.

> They should
> and it should be part of their development process. However, this does require
> additional effort. Developers need to put in the effort to learn what being
> accessible means, they need to learn about the libraries and techniques and
> they need to keep that knowledge up to date. Its very similar to the
> internationalisation issues. Back in the 70s and 80s, most of us didn't need
> to worry about diffierent different character sets. We needed a knowledge of
> ASCII and that was it. Now, when we develop software, we need to consider
> various locale issues, different character encodings and character sets etc.
> Its more knowledge we need to be aware of and that represents more effort. 

Right, but that "extra effort" is just as necessary as
the knowledge about internationalization technologies you mentioned, so
I just don't see them as "extras", but as "base skills".

> My point was that every
> additional solution increases the overall maintenance. If you have Orca on one
> hand and a suite of applicaitons written for blind/vi users, you now have to
> maintenance efforts, but you almost certainly don't have double the number of
> maintainers. If, on the other hand, we limit the number of different efforts,
> then we will have more people available for each effort able to do the
> maintenance. 

I'm sceptical if people previously working on different efforts will
manage to agree on a common interface that is definitely a compromise
and in their world, inferior to their own solution.

> Adding kaccessibility to any software adds to the lines of code. Adding to the
> lines of code adds to the maintenance. Add in additional libraries that are
> rquired to provide the accessibility framwework and you further add to the
> maintenance. 

I think the times of making a program smaller due to disk space reasons
are over, and the libraries are just there, and have to be updated every
now and then as any system software.

> If kaccessibility came for free, then vendors would just add it as it would
> increase their potential user base/market etc,  but it does not come for free.

Nothing is for free. Everything requires a degree of effort and
investment of time and work.

> It needs to be included right from the start. It needs to be a consideration
> when doing the initial design, it needs to be coded, it needs to be debugged
> and it needs to  be maintained. 

Yes. Same for every software. Part of the usual development process.
Accessibility does not double the effort if considered at the right
point of the software development process.

> The reason we don't already have accessible applications across the board is
> partially because it does represent and expense which most commercial vendors
> don't see as an expense that is offset by additional sales to blind/vi users.
> they do it when they are forced to by legislation, but would avoid it
> otherwise.

If this is true, and every vendor ONLY delivers the minimum of what the
customer wants, there would be no competition and no product awareness.

A point of sales also puts a focus on the features that exceed those of
competitors at no extra cost, in order to make a sale. 

> Other reasons contributing to the lack of accessibility are
> ignorance and lack of clarity regarding exactly what needs to be done to make
> something accessible. 

And the interpretation of what "accessible" really means. It should be
part of the specifications of a software project.

>  > > 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.
>  >
> I've toyed with the idea of writing a mode for emacs that would make it
> intergrate with elinks because it is the only text browser I'm aware of that
> has javascript support. this would be something similar to the w3m mode that
> is available for emacs now. 

I'm not sure if this is an easy approach.It may be easier to write an
emacs extension using the ecmascript libraries. Doesn't have emacs its
own HTML browser plugin?

>  > > 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. 
>  >
> True. My current employer does have a very strong policy policy regarding
> accessibility and it is certainly something that they do pay lip service to.
> However, in reality, all too often, it is put in the too hard basket. Often
> this is just due to ignorance. However, sometimes is because they can't get a
> clear answer or even a clear idea of what accessible means. for example, they
> often contact me as the 'token' blind staff member (I'm actually one of about
> 5 or 6 in a staff of about 4,000) and I find it difficult to answer their
> question. I find it hard because the question is too broad. If they ask me if
> application x is acessible, I will try it. Given I don't use Windows, I can
> only try it with what I have available. this is usually Orca and emacspeak or
> speechd. However, it may not be accessible to me, but if I was using Jaws or
> window eyes, maybe it would be. On the other hand, I'm also pretty good with
> technology and have a lot of skills that I can use which means I can usually
> find a way to make something accessible. Other blind users would not have
> these skills. So, what do I answer?

Why not give a report for each use case? "The application is accessible
with version x of Jaws/Windows, not with version y, it works fine with
Linux/orca or console-based with screenreader z".
The more positives this list has, the better for accessibility. If the
application is only accessible in a very special use case and
environment, it is likely to fail soon when the environment has to be
changed because of independent requirements.

> the situation becomes more complex because all blind users are not equal and
> unfortunately, there are some who are unwilling to help themselves. I recently
> had to deal with a very difficult and somewhat bitter individual who was not
> prepared to do anything at all to help herself. She made quite unreasonable
> demands and rejected all solutions that involved her having to do anything. 

This is probably the worst case, but even for these users who are
unwilling to invest the least self effort, there should be systems
available that do their best to do a single-purpose task.

Not everyone using a computer is interested in its technology, or finds
software customizing as exciting as we do. We have to accept that.

>  > > 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.
> 
> and my reply to your reply to my reply has made it even longer! Maybe any
> further discussion should go off list?

Maybe. We have rached 1270 lines of code, pardon, text now. :-)

Regards
-Klaus