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 -- Ubuntu-accessibility mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
