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

[Tim Cross]

Klaus Knopper writes:
 > 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.
 >

There is a very good chance I misunderstood what you were saying! Don't get me
wrong, I'm very much in favor of open source. 

Possibly my largest concern is that people regularly underestimate the effort
required to write any software that is more than trivial and the long term
effort required to maintain that software. 

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

OK. I agree the situation you outlined is quite rediculous and that an open
source solution would be better. I also agree that the insurance companies are
an expensive inefficient beurocracy that more often than not just inflates the
costs. 

However, we do possibly have a difference in definition. I wouldn't call what
you outlined above as open source development, but rather would call it
something like using an open source based configuration. In your scenario, you
are taking existing open source applications and assembling them to provide an
open source solution. Development is minimal and probably only includes minor
scripts etc that are used to integrate or glue the OSS components to provide
an integrated solution. This is probably one of the scenarios where open
source really shines. 

For me, open source development would be if you had to write the software to
do the scanning, the OCR etc. This is where the costs/time would blow out. 

Our difference of opinion is probably due to difference in definitions rather
than real difference. 


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

Yep. I've also had considerable success with open source. In the 90s, I was
employed to assist a struggling small ISP. When I arrived, they had all closed
source systems - Sun servers, commercial billing system etc. I replaced all
their servers with Linux running on i386 and sparc. The owners were totally
blown away. In fact, one of them didn't even realise I'd replaced their
SunOS/Solaris OS with Linux until it was pointed out. I then wrote a user
management and billing system, which took some time, but was still around 1/4
quarter of the cost of commercial solutions and had a lot more features. 


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

OK. I do agree that a VIM/Emacs style mode/plugin to create/edit ODF files is
possible. In fact, I bleieve there is already a very basic emacs mode for this
out there. I misunderstood your proposal. I thought you were talking about
putting an additional text based interface onto Open Office. 

Even with a emacs/vim plugin, getting the basics working would still be a fair
amount of work. It would probably be easier to achieve in emacs than VIM (I've
always found VIM's scripting somewhat limited). However, there is a fair bit
more than just document authoring in Open Office. Getting all the same
functionality into vim or emacs in a well integrated manner that is as easy
for non-technical users to use is still going to be non-trivial and would take
considerable time, but at least is potentially doable. 
 
 > For a shell/commandline expert, this is already possible, but it's not
 > user-friendly for beginners.
 >
Yes, this is something that is always difficult. I can frequently achieve
things using emacspeak, emacs, elisp, bash, perl etc that just isn't possible
for non-technical users. Its getting that last bit of user friendly finish out
of the product that often takes the most effort. 
 
 > > 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. :-)
 >

Yes, this was my misunderstanding. What your talking about is a totally
separate program that just produces (and can consume) files of the same type.
this has a much higher chance of success, but replicating the same level of
functionality is still a very large job, especially if you plan to include all
open office components, not just editing of ODF documents. I will have to
check out the mode someone has already written for emacs. Last time I looked,
they had the very basic bits working, but then development seems to have
stalled. If this is still the case, the quesiton has to be asked, why did it
stall. its possible the required functionality the author needed was achieved.
However, its also possible that after a certain point, things become a lot
more complex and difficult and things stalled because of the daunting amount
of work required. 
 
 > > 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.

Its not the interface structure I was referring to, but rather the interface
functionality. They are slightly kdifferent. If you want a text based office
equivalent that is able to create open office artifacts in such a way that
someone could use that application rather than open office and still be as
integrated and productive as the open office user, you need to include the
same types of functionality. This would include things like working with
embedded open office objects i.e. graphs, spreadsheets, images etc., support
for cross referencing, etc etc. Its this level of functionality that is often
the hardest to achieve. 
 > 
 > > 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.
 > 

could well be the case. Then again, how much of the interface stuff is hidden
in the standard awt/swing libraries? Possibly irrelevant given my
misunderstanding regarding what you were proposing. 

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

I'm not sure how/where your figures are from. I was thinking more along the
lines of the software licenses for something like window eyes, allowing a
blind user to use either MS Office or Open Office or comparing that effort to
putting a 100 days of work into Orca, which would provide users with improved
access to an even wider range of applications. 
 
 > > 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. :-)
 >

Except you don't have the applicaitons. The interface may be simpler and
easier to use, but you don't have a feature rich office suite that is
compatible with others, you don't have a web browser with reliable javascript
etc. I'm not saying that a console based interface is pointless - its very
useful and provides an alternative. However, the console based interfaces are
limited by the available text based console programs, which themselves tend to
be limited in the range of applicaitons available. If we already had a text
based office suite, then things would be very different. Your position appears
to be that we could create such a suite. My position is that while this would
be technically possible, the hours of development time this would require is
large (I think a lot larger than the 100 days you cite - I'm talking a full
functionally equivalent open office suite, not just the ability to edit basic
documents). As blind users, we deserve full functional equivalents, not
crippled poor clones. 

I don't even want to go so far as to say it isn't worthwhile. I merely feel
that it needs to be considered very very carefully and balanced against what
benefits would be achieved by putting the same resources into improving Orca.
In the long-term, I feel putting the resources into Orca would provide more
bang for your dollar than putting the resoruces into writing text based
equivalent programs. 
 
 > > 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.
 >

True. Projects like Ubuntu are helping achieve this goal. We need to keep in
mind that until a coulple of years ago, just installing and configuring Linux
was not something that many sighted users were prepared to do because it
required considerably more technical expertise than many people had or wanted
to aquire. As distros like ubuntu deal with the general usability issue, it
should become easier to create distributions that build on top of htat and
create a more ready to use environment for blind/vi users. 

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

True, but then again, we still don't have our local discounter seling boxes
with Linux pre-installed. This is all part of a bigger issue. It was
interesting to note the reactions I got when purchasing my EEEPC. All the
local retailers I checked  out except one were selling ithis netbook with the
vista version rather than the Linux version. The one retailer I found that had
a linux version try to feed me a whole heap of FUD regarding the Linux version
and complained that head office had sent it to them by mistake. This was
despite the fact the performance with the Linux version was much better than
the vista version. 

It did have a positive outcome for me though. ONce I realised the retailer
thought they had a dud they were stuck with, I was happy to offer to relieve
them of that burden for a greatly discountered price!

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

I agree, but we do need to have that 'turn key' solution first. Part of the
reluctance of many of the organisations is definitely due to ignorance
regarding the options. However, there is still some legitimate concern that
the exisitng open source solutions are not easy to configure, would likely
need additional support they are not in a position to provide etc. At the same
time, they also know that many of the proprietary vendors would find their
business model adversely affected if people began to move to open source.
These organisations have a duty of care that requires they do what they can to
ensure a good outcome for their clients. If they were to put their support
behind open source, the shift in the business model for the proprietary
players would like result in their products becoming more expensive or in some
of them leaving the market. for this reason, the various advocacy groups are
unlikely to support open source fully until they are confident that it is in
fact a viable alternative. Until we have that turn key solution, I don't think
it really is a viable alternative for many. 

Having said this, I do thing these orgnaisations should be putting more
resources and support behind open source than they currently do as I believe
in the long term, it would be more beneficial. 

 > > 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.
 >
There is certainly a need for more education and there is need for political
change. However, the open source solutions still need to mature. projects like
oralux, vinux etc are all a good start along this road, but we have a distance
to travel yet. 

If we push the agenda politically and do it too early, we could do more damage
than good. At the moment, a lot of the resistance is due to ignorance
regarding the open source solutions. However, ignorance is easier to deal with
than bad past experiences. If you tell someone about the open source
alternatives and they know nothing about it, they will be more willing to give
them a go. However, try convincing someone who has given them a go and failed
because they coldn't configure them correctly or because they found the system
unreliable or otherwise limited and you will have a much harder battle. 

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

In theory, anyone can contribute to an open source project, but in reality,
this isn't always true. Life matters can affect your ability to contribute.
For blind/vi users, this is even more true because a working reliable system
is often more critical to their work, leisure and even independence. It is for
this reason that I run two systems at home - one bing my stable reliable
environment and the other being my experimental system. Many blind/vi users
don't have this luxury of multiple systems or the technical confidence to run
a mutli-boot or vVM image system that would allow them to do this. Many find
the initial setup/configuration too difficult to do. Given that we are already
talking about a relatively small community, you end up with an even smaller
number able to assist. 


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

Yep, this is the old fear of change issue. Its not limited to blind/vi users,
but it can be more pronounced. The fact that most support agencies don't
provide any level of support for open source solutions makes this situation
worse. While it would be nice to see this, I don't think many of these
agencies even have the resources to do this even if they were so inclined. 
 
 > > 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.
 >

Well, its true that you will usually be most confortable with the system you
first used. However, the number of people who have never used a computer
before they lost their sight is shrinking every year and for those born
kblind/vi, they will usually be introduced to Windows very early. The number
of people you are likely to find with no prior computer experience is small
and getting smaller all the time.
 
 > > 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 mostly agree. I do see change occuring. A number of school districts in the
US have moved to Linux quite successfully. The move was driven by cost rather
than anything else, but thats fine. Germany, as you would know, has made some
significant moves towards Linux in a number of government departments. Brazil
has been very strong open source supporters. Things are changing.

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

I don't see 'ignoracne' as a prejoritive term. Being ignorant of something is
not a crime or even something to be ashamed of. Likewise, I'm blind, not
vision challenged!

Actually, I laugh when people talk about me being visually impaired. I often
say "What, I'm visually impaired - do you mean I'm difficult to see or just
ugly! I then often tell them they mean vision impaired. 

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

Yep, we should always speak up when there is a problem, especially when we
know it can be easily fixed. I've often said to people who want to know if
their site is accessible that they should just install one of the available
screen readers, doesn't matter if its open source or proprietary, turn off
their monitor and try it out. If they can't follow/use the site, its not 
accessible!

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

Hmmm. I'd need to think about that. I'm not 100% convinced that is totally
reasonable. If we take it to an extreme. What if we have someone running
Windows 3.11 with winsock and a very very old browser. If they cannot access a
page because that browser doesn't support javascript or style sheets or
whatever, is it reasonable to argue the page is inaccessible? I realise this
is being a bit extreme, but it begs the question where do we draw the line. My
concern is that we need to facilitate the ability of vendors to do the right
thing, not create so many obstacles that they can never succeed. If they feel
they will never succeeed, they just won't bother. 
 
 > >  > 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.
 >

It is also important to recognise the good work these proprietary vendors have
done to make things morer accessible. for example, GW Basic and even to some
extent, Freedom Scientific, have put a lot of pressure on Windows to get them
to add the necessary libraries and hooks into their OS that allows the screen
readers to work as well as they do. While it is true they have a vested
interest in doing this because it improves their product, it is also true that
incorporating such facilities enables other open source screen readers to
achieve better outcomes. 
 
 > >  > > 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.".
 > 

Really? I hear this all the time. Most windows users I know constantly
complain about aspects of the software they use. Every windows user I know who
has any experience with any other OS complains about the constant Reboot Now
requirements or the nightmare called the registry or .....

Of course, if the software is in a monopoly situation, complaining achieves
little. This is why OSS alternatives are so very critical - at least it one of
the reasons. 

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

Maintenance issues, and I'm talking sofware maintenance, is the same
regardless of whether it is proprietary or open source. The diffeences are
that in proprietary software, profit will determine maintenance schedules
while in OSS, available developer resources will be a defining factor. At the
end of the day, all software either needs to be maintained or suffer bit rot. 
 
 > > 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.
 >

I'm divided on this. From an ideological stand point, I'm very much in the FSF
camp. RMS was quite right regarding the danger of a society becoming dependent
on software for which the knowledge and algorithms it uses are closed and
become essentially secret guild knowledge. On the other hand, there are
sectors where there just isn't equivalent OSS solutions and the proprietary
vesion is the only alternative. I've argued at length with RMS on this. For
example, until the last few years, there simply wasn't an open source TTS
engine that was anywhere near the quality of the proprietary ones. RMS'
position was that rather than use the proprietary one, I should sit down and
write an open source one. My position was that this wasn't practicle. I need a
solution now and it would take me months, maybe even years, to write an open
source TTS that was of equivalent quality. In reality, I might not even have
the skills or knowledge to even achieve such an outcome. In the end, I suspect
I was branded as a sell out freedom hating individual who was part of the
problem and not the solution. My position is that I will use the open source
solution if it is acceptable, but will use a proprietary solution if there
isn't a good enough oss version. 
 
 > > 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?
 > 

I certainly agree that governments tend to waste money, or at elast use it
inefficiently. However, I also think, despite the GFC, we have been existing
in a fairly wealthy bubble that is going to burst, either due to poor
worldwide financial management decisions or due to the changes that will occur
as a result of shifts in envrionmental priorities or energy resources etc.
When this occurs, the funding for minority areas will be the first to go.


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

Standard in the sense that all users within the organisation are using the
same software versions i.e a standard 'image'. 

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

yes, some employers do see employing anyone with a disability as potentially a
burden. Unfortunately, many employers don't really care about providing a
means for someone to realise their potential. What they want is a job done and
they want to get that job done as cheaply as they can. If they have a position
to do x, they are not interested in employing someone to do y even if that
person might do it better than whoever is currently doing y. 

this is all made worse by the fact we have some very very poor management
practices existing int he current economy. management tends to have a very
short-term view. Decisions that reduce costs in the short-term are favored
even when they increase overall costs over the long term. In general, focus is
on the micro rather than the macro. It strikes me very much as along the lines
of false economies and I'm stunned more companies haven't realised this. 

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

Agreed. Current management practices, with few exceptions, are in a very sorry
state of affairs. I recently read a book about China. It is interesting to
note that at one time, China was incredibly advanced compared to the rest of
the world. Then, a subtle change occured where the pinacle of success was to
be a government beurocrat. Science and engineering was no longer considered a
notable pursuit - all the successful and smart people were becoming government
beurocrats. I think its no coincidence that at that time, china effectively
stopped progressing and slowly slipped back while the rest of the world
advanced. 

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

I would agree that many in-house applicaitons now adopt a web baed interface,
but there are still many that don't. In the case of web interfaces, it can be
easier to get modifications that will make them accessible. However, you can
still have a web interface that technically follows all the accessibility
guidelines, but is till almost impossible to use for non-sighted users. 
 
 > - 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.
 > 

While possible, its often difficult to get this outcome, especially in larger
orgnisations. Often, decisions are cost based rather than  based on eithics,
morality or legislative requirements. If a manager is faced with the decision
to employ a blind individual and spend $50k updating their in-hosue software
so that they can use it or just employing a sighted person, guess what the
decision is likely to be!

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

Of course, but choice is rarely as stright-forward in practice as it may seem
in theory.  
 > >  > 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.
 > 

My poin was more about the situation where we concentrate on creating text
versions of software rather than on systems that would make existing GUI apps
accessible. In this situation, without good solutions that make GUI apps
accessible, I'm likely to be left without a solution for those situations
wehre specialised software is involved because there isn't a text version. I'm
talking extremes to make the point that this is why I find projects like orca
so critical and my concern , or at least issue, that we need to consider at
what point is it better to put resources into something such as Orca over
something like a text based environment. ideally, we would have both, but in
reality, we have a limited resource pool. I don't even know what the answer
is, but it is something that needs to be considered.

 > > 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?
 >
If the vendor says no, there is still the legal route due to most countries
have some form of accesibility legislation. If its too expensive, then that
could be a real issue. However, I still feel the possible options are still
better than if I only had a text based interface. 

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

thats true, though I'm not convinced this will continue to be the case. there
are also many applications that don't have that type of architecture. What we
do know is that pretty much every user applicaiton has some sort of interface.
some have mulitple multiple interface options and some do not. We can agree
that on the whole, text based interfaces are pretty easy to make accessible.
GUI interfaces are not always so straight-forward. It should also be noted
that most GUI screen reader oreinted programs, such as Orca can also handle
text based programs pretty well. The converse is not true of text based
accessibility options. 
 
 > >  > > 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.
 > 

I would strongly recommend looking at either emacs and speechd or emacspeak.
Both are based on a similar approach. the main difference is that speechd
tries to be a bit leaner and has a smaller impact on standard emacs operation.
Emacspeak takes a slightly different approach. It will attempt to avoid
modifying standard behavior, but will not hesitate to do so if this will
achieve an improved interface for the blind/vi user. sometimes this does
result in significantly changed emacs behavior, but usually at a benefit
(IMO). 

The nice thing about it is that nearly all emacs modes and modules will work
out of the box without the need for any modification. When you do need to, its
quite straight-forward. Once you hve emacspeak installed and working, you have
access to the web, email, numerous programming environments, high level
document preparation using tex, or docbook texinfo, access to all the standard
modes, calendar, appointment management, spreadsheet, sophisticated personal
information management, terminal emulation, sophisticated remote file access
and editing, irc clients, jabber/xmp clients, RSS readers/aggregation and much
much more.  In addition, emacspeak adds increased kintegration with many web
services, including google apps like greader, gcalnedar, gphoto, etc support
for XSLT transformation of web pages and an extension system that makes it
quite easy for those with a bit of technical skill to extend the system or
customize it to what they want. 

The two main barriers to emacspeak at present are the learning curve for emacs
and the fact that setting up a supported TTS server can be somewhat difficult.
The really good aspect is that as emacs is developed and new functionality
added, you tend to get that for free. 

One of the things I like best about it is that using a bit of elisp, you can
prototype and experiment with possible accessibility solutions. for example,
emacspeak was the first system I know of that used 'voice locking', a concept
similar to font locking, in which different voices are used to communicate
additional information, such as using different voices for text in italics
compare to text in bold or underlined or having different parts of web pages
spoken in different voices etc. It was also one of the first systems to use
sound icons to communicate information, such as the end of some process or
success failure in a search etc. 

It isn't the right solution for everyone, but is certainly a solution that
anyone with good technical skills should investigate, even if its only to get
ideas or borrow features for other systems. 

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

don't worry about it, it was somehwat tongue in cheek. I was just noting that
you were commenting on my personal motivation or state of mind. I sometimes
find it a bit frustrating when you are debating some issue and someone tries
to make it about personal attributes rather than sticking to the question at
hand. the pint was that whether I'm frustrated or not has little baring on
what I said. In reality, I'm far from frustrated as I'm less than interested
in most of the more recent developments anyway. I have no interest in social
networking on face book or twittering to the world that I had beans for
breakfast. Much of what has been popular in technology in the last few years
leaves me a little less than impressed. I'm not even a big web surfer. I use
it mainly for reference and to keep up on developments in technology. I don't
tend to spend hours aimlessly surfing the web and I don't tend to have a
social network - I prefer my socialising to be in person. Would rather sit
down and drink a few good beers or a good bottle of red with real people than
spend hours with virtual friends in som eon-line forum. 

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

I reckon forget about the hand operated mouse. We sit at the desk for hours
and all that time, while becoming fat and flabby, we could be using our feet!
Lets start using our feet to control scrolling or paging between virtual
desktops or minimizing/maximizing windows. Get all the benefit without having
to move your fingers off the keyborad and stay a little fitter! The hardware
exists already - its just a matter of getting people to realise the benefits.

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

Yep. this certainly exists for emacs already and even the ability to speak
differences in different voices is there, thanks to emacspeak. Not sure about
vim, but I expect its out there somewhere. However, this is still a lot ore
cumbersome and takes a lot more work for the end user than the track changes
provided in things like word. 


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

Hmmm. Not sure I agree. In a text based console, your restricted to a w x h
array of fixed sized cells. Lets say 80x25. In a GUI display, your at the
pixel level, which itself is also a w x h array, but with more fine grained
control. You can fit more information on the screen because you have options
for different character rendering, including things like supscript and
superscript and you have the options to align things differently. this can
make it possible to use the available real estate more efficiently than you
can with a fixed cell based approach. You can also use symbols and other
visual aids more effectively. 

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

If we assume the text interface is only able to handle the rendered text,
consider a GUI interface that provides additional information based on how the
information is layed out. A screen reader can be smart enough to provide a
spoken description of that layout that can add meaning to the content.
However, in a text only representation that is restricted to the text layout
facilities of a console, this is much harder to achieve. Screen readers based
on a GUI environment, can provide additional information on the content based
on analysis of the data. For example, it could be possible to have a screen
reader provide the summary of a bar chart or pie chart. Now, you could
possibly do something similar in a text based interface if the data
representing that screen artifact was available and in a form that allowed it
to be interpreted, but it would take a lot more work. My argument isn't so
much that you can't do it, but rather it will take more work to do it and it
will be more complex and therefore more likely to have bugs and require more
maintenance. 

Of course, I may be thinking about this the wrong way. Its easy to be
constrained by what you know and are use to. More imaginative abstract
thinkers may be able to achieve this easier than I could. Essentialy, I guess
my argument boils down to the fact that in a GUI environment, you have more
fine grained control over how things are rendered which means you have more
options. 

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

You should look at some of the work T.V. Raman has done at google. He has
developed javascript libraries that actually make applicaitons more
accessible. 

The use of javascript to perform graphical operations, such as dragig and
dropping a photo is an interesting use case. For sighted people, this is a
really good feature. For blind/vi it is of no use. Is there an equivalent that
is usable by both groups? If not (lets assume not), what should happen? I
guess what I'm asking is if it is reasonable for there to be some
features/functionality that just isn't accessible. My feeling is that the
answer is yes. Its like touch screens. Pretty much unusable for blind users.
However, a useful and valuable technology for sighted users. What about a
really extreme example. Driving a car. This is something that remains
inaccessible to blind users. Playing devils advocate, is it possible there is
justifiable functionality with respect to computer interfaces that will remain
inaccessible to blind/vi users? At what point does it become reasonable to
argue that just now, the technology is not sophisticated enough to provide
access to the boind/vi? Does such a pint exist and if so, how do we rrecognise
it? At what point does expenditure on resources to make something accessible
become unjustified. for example, personally, I don't care if a web site for
managing your photos iis inaccessible. I have not interest in photos so I
don't care if sites to manage them are not accessible. Is legally or othewise
forcing a company to make something accessible even when there is no demand
reasonable? What if doing so makes the otherwise viable business model
unviable? Is there a point at which insisting on accessibility does us more
damage than good? 

I don't know the answer and am even a littlereluctant to open this pandora's
box, but maybe its worth thinking about even if it ends up being dismissed as
just a firthy.

 
 > >  > 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.
 > 
yes, have a look at the mozlab repl. Essentially, it provides a
read-eval-print loop inside firefox. You can modify javascript 'on the fly',
retrieve various bits of the document, load custom javascript and all sorts of
other interesting things. Raman also shows in one of his blogs how to run
firefox from the console without X windows using one of the virtual x servers.
Theoretically, you could have a basic text html rendering widget that just
retrieves the rendered data from firefox and displays it. You may find his
technique for running GUI apps from the console useful in other scenarios as 
well.


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

I agree they shold be base skills and I hope eventually that is what happens.
However, they are extra effort until we reach this stage in the same way that
initially, coming to terms with internationalisation was an additional 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. 
 > 
 > 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.
 >
Yes, I'm skeptical as well. often ego and time investment together with the
fact people are more comfortable with what they know makes it hard to agree
and pull together. What can I say, its the human condition I guess.

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

Nothing to do with disk psace or even memory consumption. Its just a matter of
stats. the more lines of code you have, the more lines of potential bugs. The
more lines of code the more difficulty in finding the line with that bug. the
greater the complexity, the more difficult it is to update for evolving needs. 


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

Exactly. Incorporating kaccessibility is no different. accessiblity 
 
 > > 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.
 >

Obviously issues of kcompetition need to be taken into consideration. However,
no vendor is going to add features to their software if they don't see adding
such features will increase their sales more than the investment in adding
those features. Vendors can get it wrong and add a feature which they think
will give them an advantage or will increase their market share, but they will
not add anything if it doesn't increase profitability. 
 
 > 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. 
 >

Only if adding that kfeature is seen to be less than the revenue (or expected
revenue they will recieve. No vendor is going to add a feature that costs them
$100 dollars to get a single $50 sale. they might do it if they expect to keep
that customer and seel them upgrades or licenses that will, over time, return
more than the added feature cost. 

 
 > > 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?
 >
No not really. There is Emacs/w3, but that is suffering from bit rot and lack
of developer support. The code base needs to be completely refactored and
re-implemented. the amount of work to write a web browser is huge, It is even
more daunting with elisp as you ahve no exisitng html rendering libraries - it
would be like starting from scratch. 

 
 > >  > > 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 main reason is that, to be honest, its not my job. I have a full time job
I'm employed to do and I'm not interested in becoming an accessibility tester,
plus, htey are not interested in paying anyone to do this. I'm also not
interested in having to maintain multiple windows systems with multiple
versions of jaws and window eyes. 

Obviously the right solution is to have a dedicated tester with the necessary
resources to do this. This is what they wold do if they were serious. but as I
said, its all really just lip service. another modern management ailment -
just get ticks in the boxes and forget about practicallity or accuracy. 


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

Ageed. At the same time, its not the rest of thw world fault we have a
disability. There is a requirement for us to try and do what we can to help
ourselves. 
 
 > >  > > 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. :-)
 > 
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.