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

[Tim Cross]

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

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. 

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.

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

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. 

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. 

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

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. 

some projects, such as Orca, have (at least in the past) recieved funding and
commercial support in the form of developer resources. 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).

At the same time, I think we also need to balance ideology with pragmatism.
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. Many blind/vi users are not in a position to contribute
to open source projects. 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.
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.

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! 

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. 

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

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? 

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

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

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. 


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

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

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.

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. 

Unfortunately, this world doesn't exist. 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. 

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

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. 

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

Many larger organisations now adopt a standard operating environment to avoid
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. 
 
 > 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.
 > 
yes, but again, these are issues that are not specific to accessibility and
ones that need to be resolved by users as a whole. At least, if we are using
the same technology and applications, when theya are resolved, we will get
that benefit. 


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

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.

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


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

 
 > > 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. My argument is that we must have
both. Only having applications specifically designed for blind/vi users will
result in us being second class citizens in the technology world. 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. 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. 

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

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. 

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. 

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. Using this, you can express more information in a
screen than you can with text. Sure, we can use sound icons etc, to do this,
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. 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. 

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

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. 


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

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. 

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

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. 

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. 

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

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

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

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

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. 

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