Wednesday, June 4, 2008

Keyboard

I'll start with the most basic requirement for software accessibility for the visually impaired - allow all navigation and functionality through the keyboard.
It is commonly known that blind users use a software called a 'screen reader" that gives them an audio output interface to the computer instead of having to look at the traditional video interface (the screen).

However, there is also a difference in the input interface that blind users use. They use only the keyboard and not the mouse -unless if they have to.
So, if you want to make your software/web sites accessible for the visually impaired, it is not sufficient to just allow screen readers to read the output. It is equally important to allow users to use only
the keyboard for all input and navigation.

This simple usability requirement has a lot of ramifications when it comes to user interface design.
The last time you created those fly out menus on your Web page, did you ever try using them without a mouse?
The last rich client online trading application with a lot of panes for displaying the different parts of your screen. Did you try moving across those panes using the keyboard alone?
The drop down list that posts back the page on selection change. Did you try selecting the third item in that drop down with the keyboard?

The answer to the above and other similar questions is "no" for most applications and Web sites that I've seen - even as a part of the team that was developing it.

For screen reader users, it is essential that they be able to do all input and navigation through the keyboard. And interestingly enough, it is very very simple to test. Simply deny the luxury of a "mouse" to one person in your QA team.
And treat everything that person cannot do as bugs.
this simple test will have you cover over 50% of the accessibility chalenge - the input interface.

Having said that, I need to also add that this simple test may bring out all the accessibility bugs but their solutions may not be simple.
If you're the one trying to get accessibility in, you'll get push back from first the "tester who was denied the mouse", then the user interface designer who designed the screens and navigation flow, the developer who has to do all that "extra work" to implement the new "more complicated" design, the architect who needs to come up with a "new technical solution" for something that developers in his/her team could otherwise do on their own, the project manager who just cannot understand what all this re-work and extra time is all about and so on.

... so, good luck!
The subsequent entries in this blog will deal with specific tips on how to make apps more keyboard friendly.

No comments: