Tuesday 6 May 2008

When accessibility isn't...

Nothing is more frustrating than encountering some user interface element that doesn't quite work the way you expect it to. Of course, that simply be a reflection of wrong expectations. A review of existing accessibility technologies leads me to believe that the notion of 'wrong expectations' is more often than not used as an excuse for poor decisions made at the design stage of accessibility support.

And why not... Most (if not all) GUIs now support keyboard shortcuts and various other forms of keyboard manipulation, because people tend to use that. And when you already have keyboard based UI interaction, you're mostly done with providing accessibility.

The problem with this logic is the assumption that accessibility is somehow equivalent with keyboard interaction. And that the ability to interact with a UI element is equivalent to that UI element being accessible.

Enter centre stage: "combo box"

You know, the space-savings widget that allows you to either enter arbitrary text or select from a list of options (presented as a pull-down list that opens and closes by 'clicking' on a convenient little button.) And ever GUI implementation I have looked at makes it completely accessible by means of keyboard interactions. You can enter arbitrary text, and you can pull open the list and select from that list. Nifty!

Time for an experiment: Use your favourite GUI environment, locate a nice combo box, and hide your mouse/touchpad/whatever for a little while. Now, type some text in the combo box. All is well. And it is time to use the real power of the combo box: open up the list of options, and go down the list in search for an entry that is acceptable to you. Let's happily assume that none of them are, so simply close the list again and we'll just settle for the arbitrary text that you typed... Uhoh, where did it go??? Did it get replaced by the last option you arrowed down to before closing the list? There is a very high probability that you will in fact experience exactly that behaviour.

Time for another experiment: Now do all of the above, but use your mouse/touchpad/whatever. I highly doubt that you will find your carefully typed text wiped out by something else.

Isn't it amazing? Two forms of interaction on the same widget have different interaction semantics, yet they are consider equivalent. The widget is considered accessible. Yet, it isn't. It is usable. It can be "accessed". But that's not the same as saying that it is accessible.

No comments: