disabilities

[Bruno Girin]

On Tue, 2010-05-25 at 03:25 -0500, Kenny Hitt wrote:
> Hi.
> On Mon, May 24, 2010 at 10:52:59AM +0100, Bruno Girin wrote:
> <snip>
> 
> > how well (or not) they are followed by web site designers. My experience
> > in the industry is that there are very few designers who are aware of
> > standards and why they should be followed. And even when they are aware
> > of accessibility standards, they don't understand them well enough to
> > argue the case for following them, especially when it is perceived that
> > following the standards will increase the development cost. I constantly
> > face this problem in my day job: every time I need to write
> > specifications for a new web based system, I include accessibility
> > guidelines and invariably I get answers like "that will increase the
> > cost by X" or "that will delay delivery by Y" when it's not an outright
> > "we can't do that".
> > 
> 
> One point you might want to mention when they start talking about cost is that if I can't use the
> web site I'll ve forced to call and talk to a person to get what I want.
> Which has a lower cost, making the site accessible or paying someone to answer the phone?
> I don't have any data to know the answer.  Hopefully, someone has done such studys.

Yes, that point is always made. But because nobody ever has any numbers
to identify how much business they would lose by not making their web
site accessible, that argument generally doesn't work as well as it
should. And what generally happens is that accessibility is added to the
requirements as a low level priority (which usually means "we'll do it
in release 2, 3 or whenever we can"). This is obviously the wrong way to
do it, considering that web site accessibility is similar to
multi-browser support and multi-language support in the sense that it's
not rocket science and it's quite cheap to do if you include it from day
1 in your design. On the other hand, if you try to retrofit it to an
existing system, it can be prohibitively expensive because it
potentially requires a complete re-factoring of that system.

As a result, getting accessibility accepted as an essential requirement
is a lot easier on a green field project. The worst situation is when
the business users have decided to buy a piece of software from a third
party vendor without involving IT in the initial discussions. In the
first meeting I have with the vendor I'll always ask about accessibility
support. The response tends to be a blank stare, then a statement like
"sorry, our product hasn't been designed for this" then some more
argument and a statement like "ok, we can do this but it will cost you a
lot and you will lose functionality X and Y", which are of course the
functionality that sold the product to the business because they looked
cool and use so much Javascript wizardry that they are completely
un-accessible. That sort of response is usually a symptom of a badly
designed product, which will potentially be a support nightmare once
it's in production. But of course, that's of no interest to the
project's stake holders as it's a potential future cost rather than an
immediate one.

Sorry about the rant, it's probably completely off topic by now!

On the other hand, open source has an advantage here, in the sense that
the money considerations that usually become barriers in the corporate
world are not (or less of) an issue with open source. Instead they
translate to time, effort and knowledge on the part of the application
developers. The good thing is that we can all do something in terms of
spreading the knowledge and some of us can help with time and effort.

Bruno