Advocacy Group For the Blind Slams Google Apps 287
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."
Re:Disabled people (Score:5, Informative)
Re:Disabled people (Score:4, Informative)
I have a bit of a vision impairment, and I can tell you, it's hard for even partially sighted people to use Google tools. It pisses me off every time there's non-speaking text, and what the heck is up with gmail? Android still has major problems, too, with the web browser and e-mail not talking. It's not illegal to make tools that don't work well with screen readers, but no public institution should require people to use these tools.
Re:Too bad (Score:2, Informative)
Unless you're only into games and Photoshop, for most people computers are primarily a textual medium. The visual bits around it are just there to make the text more accessible, but you can can generally use computers without the eye candy. Most normal software can be easily navigated using only the keyboard, and there's software that reads the captions of windows and the text in controls.
But the web has been a great step backwards for blind people, and for no good reason other than that most of the people behind the web technologies weren't blind. But there is no particular reason why websites should be so terrible to navigate by keyboard - it's still mostly text with a few input fields here and there. But in practice a lot of websites are terrible and Google Apps is one of the worst offenders.
Because I don't want to end on a negative note, I would like to point out that computers haven't made life worse for the blind, quite the contrary. Cheap text-based communication has ruled out a lot of social disconnect. And it is much easier to get an e-book or internet article and have your computer read it to you or present it using a Braille device, then it is to hope that the local library has a heavy clumsy Braille book that happens to interest you.
Maybe one day you will befriend someone who is blind and maybe that will give you new perspective.
Re:Disabled people (Score:5, Informative)
that sounds like the schools problem, not google's
Hence the reason NFB has asked the DOJ to investigate New York University and Northwestern University.
Been there, done that ... (Score:5, Informative)
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.
Re:Disabled people (Score:4, Informative)
Why is it bloat to support disabled users in your application?
1. Red/green colour blindness is very common and is about choosing the right colour palette for your icons, etc. No bloat.
2. Adding keyboard accelerators to your menus and dialogs means that power users and people who predominantly use the keyboard over the mouse can be faster and more productive. Adding this is an extra '&' character per menu / dialog label string. Minimal bloat. There is also finger memory -- if you support something other than Ctrl+P for printing your users are going to make mistakes (Lotus notes is bad at this, using F5 (usually refresh or presentation on Windows) for log out!). Same goes for radio button group cycling, tab stops, etc.
3. Showing all text as text controls/elements helps when diagnosing problems (can be copied & pasted) and allows for better localisation support.
4. Adhering to colour schemes for background and text elements is useful for people who do not use white background/black text (e.g. having a black background to reduce screen glare). This is a matter of using the correct APIs when drawing special/custom elements. Minimal bloat.
5. Adhering to font sizes has benefits for people using high-DPI/HD displays or are projecting the display. This is a matter of using the correct APIs when drawing special UI.
6. Following the defined metrics on a system will mean that it should work at different DPI settings (e.g. 96DPI vs 120DPI on Windows), different themes (e.g. on GNOME and KDE desktops) and on touch-based devices such as tablets and phones where the hit-test area is important.
7. Adding a fallback alt="..." for images on web pages is not difficult and does not add that much bloat. It also means that if a user has a slow internet connection, they can disable images to reduce bandwidth and still understand the pages they are viewing.
8. By making your program/website accessibility aware means that it is also easier to automate the testing (i.e. through the acessibility APIs like MSAA/IAutomation2/UIAutomation on Windows and Gail on GNOME).
If you follow the Windows/GNOME/Qt/KDE/Web guidelines and use the standard provided controls you will get most of the accessibility for free. Also, more often than not accessibility support improves the application for other users as well.