I want to make sure a piece of software I am writing is usable by people with various disabilities such as blindness and an inability to use a mouse and / or keyboard.

Unfortunately I have no experience with things such as screen readers or other methods that disabled people use to make using a computer easier / possible. I've never really had much experience with disabilities at all and unfortunately I don't know any disabled people who I can ask.

I was wondering what other people do to make sure that their software is available to a wide range of people with varying abilities?

This seems to be a subject matter that is often ignored by developers and I think it is a real shame.

Edit: If anyone has any specific information related to desktop development in addition to the information already provided in the answers below I would be grateful. Particularly methods that apply to cross platform development on Windows, Mac OS X and Linux.

I suspect the most important thing is to follow the user interface guidelines for your platform as closely as possible. Getting colour/font/whatever settings from your O/S is obvious, but there's more subtle things, such as making sure that dictation and other accessibility software can navigate your dialogs and that screen readers read the correct text for the dialog field that has the focus. The closer you are to the standard user interface guidelines for the platform, the more likely these things are to just work.
–
Steve314Dec 9 '12 at 16:54

Thank you both for the comments. Obviously I try and follow the interface guidelines as a matter of course but I'll attempt to adhere even more strictly in the future. As for a double blind blind (heh) test I'd love too but I'm not entirely sure I have access to enough people with varying disabilities (it is not just blindness I am interested in) although I'll see if there are any charities that help with this kind of thing.
–
CromulentDec 9 '12 at 17:35

You could try to get disabled people to use your software and give feeback?
–
marco-fisetDec 11 '12 at 21:38

2 Answers
2

After you read the scores of documents from the 90's on usability, you can test some things like colorblindness with color filters. Colorfilter lets your view a page or image as someone with different types of colorblindness would. The W3 group also maintains a list of tools that are helpful when designing for inclusion.

For screen readers (and in general), don't link to cats. Rather, link to a search for cats. This is especially important for screen readers which often scan a document for all the links and read them back to the user. It's not helpful to anyone if they just hear, "link, link, link, a link, this site, go here, link" repeated back to them from their screen reader.

Lastly, whether for disabled people or not, you should always make your applications and websites easily navigable with only a keyboard.

Use the W3C's Accessibility Guidelines. Most of it is fairly straightforward, but it's important to understand it and implement it. In particular, focus on good semantic markup. E.g. actually use H1, H2, etc, instead of making a DIV look like an H1.

Create a site that works well without JavaScript, and then enhance some of the functions with JavaScript.

Using something like Web Developer's Toolbar, disable JavaScript and disable all styles. Refresh the page and imagine what it would be like for a screen-reader to try and convey it in any meaningful way to someone with vision challenges.

Make sure that all links work well with JS turned off. JS is evil when used for link activation. (This advice applies to search engine bots, too.)

Find a website that is talking about accessibility issues (e.g. accessibilityforum.com and ask for volunteers to test your site (or app, or whatever).

If this 'feature' can be overridden, then it was a bad choice of default by the programmers; if it can't be overridden then the framework is broken, either through incompetence or malice.
–
Peter RowellDec 10 '12 at 16:39

Technically, it could be worked around, but to do so would be to throw away MOST of the framework. My own limited experience with screen readers is that they had no problem with JavaScript based links that triggered full page reloads. AJAX seemed more problematic from a notification point of view, but in both cases, the JS fired as you would expect. It was just a matter of the user being aware of what was happening after. For the js-based links, the user assumed the page would post, and it did, so there was no problem.
–
GrahamDec 10 '12 at 17:39

Thankfully I generally use Django for web development so that is not an issue. I wasn't specifically talking about web development in my original post (I should have been more specific) but this information is still useful. Thank you.
–
CromulentDec 11 '12 at 21:17