Slashdot Mirror
Advocacy Group For the Blind Slams Google Apps
angry tapir writes "The National Federation of the Blind claims that Google Apps lacks required features for blind people and wants the US government to investigate whether schools that adopt the e-mail and collaboration suite run afoul of civil rights laws. The NFB is asking the US Department of Justice's Civil Rights Division to probe whether New York University and Northwestern University are discriminating against blind employees and students through their use of Google Apps' Education edition."
Blind people designed Slashdot's look you insensitive clod.
I have worked with the NFB on projects before, and prior to that when I was contracting at IBM, I was the section 508 guy for my group. I have a decent bit of insight into accessible software development, and push for it's inclusion at my current workplace.
However, realize that the NFB is an advocacy group. They do not care about business needs, or the cost of adding support for screen readers to your application. They could care less that you need to spend 40% of the project costs retooling, or increase the work effort by 20%, in order to support approximately .3% of the population. They simply want it to work for them - as it should be, and the rest is your problem.
So, what's is that problem?
Well, businesses have roadblocks in realizing that providing accessibility standards for your software is a losing proposition - the NBT actively attempts to cloud this viewpoint or strike it down as morally objectionable. However, it is unlikely that the level of effort that goes into producing an accessible application or website will ever show any reasonable return. Additionally, as with all software, the later in the game is is added, the more expensive it is - so retooling an app is worse than the cost of folding it in from the beginning. So we're looking at a big expense with no return - low ROI.
Beyond all this, non-sighted or otherwise impaired individuals are already coping with non-accessible interfaces on a daily basis. They have specialty software that helps them cope with this, and in other cases, there are learned workarounds. Just like a Microsoft product user, they are conditioned to accept the failures, and while aggravating, they can usually accomplish their goals regardless.
So, what are my points?
1) Never agree to retool an existing app (though you can accept submissions)
2) While in the planning stages decide what level of accessibility support you're going to aim for. It's increasingly expensive, especially the QA side where there's a severe demand for accessibility testers. Make a rational cost-based analysis. Some things you get for free just by adhering to strict HTML standards (like providing alt text for your images AND LINKS, or properly labeling your tables with a summary attribute, and column descriptions) for webapps.
3) Don't ever sweat the compliance if it's hard to do at any one point - it's simply not financially worth it. Go for as much as you can. All the rich "web 2.0" features which make the difference between a sale or a miss don't translate well in the accessibility world. It won't help your product if it's accessible if no one is going to use it. Remember - unless the laws change, compliance is usually a 'good to have feature' - not a 'must have'. Prioritize it well.
4) Harsh though it may seem, you can rely on your disabled users to provide their own solutions. Your software is unlikely to be a required resource - worse comes to worse, they can always use something else willing to lose money by supporting specialty groups.
If you want applications stop fucking doing them in a web browser. Write a real application. Otherwise use HTML to make a web page. If we could outlaw web 2.0 it would be wonderful.