Sunday, October 21, 2007

Quick Tip: Start Thinking About Accessibility

One aspect of usability that I haven't spent a lot of time exploring here is accessibility. Depending on your company or industry, this is a subject that may or may not mean a lot to you. A simple definition of accessibility is that it is concerned with making all of the functions of your application readily available to as many people as possible, regardless of ability. This may take the form of a well-designed webpage that behaves properly when accessed by a screen reader device for a visually handicapped user or making sure that if you design a drag & drop feature that there is an equivalent way to carry out the action for a user that is unable to use a mouse. Certainly making your applications completely accessible can add an entirely new dimension of complexity to the design process, but you can start by taking small steps when you are working in your prototype phase (you *are* using LFPs, right?). When you are working on an initial design for an application, take some time to consider any challenges various user types might encounter when working with your application. Then, try to figure out ways to mitigate these challenges while still providing a compelling experience for the majority of your users.

Let's take a very common example from Lotus Notes applications. Almost everyone can find at least one app in their environment that has views that utilize colored icons to denote some kind of status. Maybe it is a project tracking program and the adherence to the project schedule is represented by a red, green or yellow icon. Pretty standard, right, and easy to understand? Yep, most certainly...unless you are color blind. In this case, those icons might all look the same and without some other type of indicator, that user cannot determine which projects are in trouble and which are doing well.

How might we rectify this situation for our color blind user while maintaining our simple paradigm of using icons to denote status (which allows us to effectively use our screen real estate to show other important info)? One idea would be a slight redesign to use different shape icons in addition to different colors. Thus, our initial design becomes:

With this very simple tweak, we can still make effective use of icons to relay document information, still use color (which in this case is a powerful metaphor) and enhance the accessibility of our application for our visually challenged friend. Not a bad day's work for a small investment in time.

Accessibility is, as you would expect, a very broad topic and I've just scratched the surface with a simple example. What I hope to accomplish with this post is to get you thinking about the topic so it can be in the back of your mind the next time your start working on a design. Anytime you can overcome these small hurdles, your application is on its way to better usability. Good for you!

The screenshot here was respectfully taken from Automation Centre's excellent Tracker suite. Check 'em out.

Labels: ,


By Anonymous Elf, at 3:27 AM  

I actually have been thinking about this, but by accident, rather than design. I used small icons, looking like Norwegian traffic signs to signal the status of a project.

A while back, an employee told me that he was very surprised that I had been so forward thinking that I prevented people who are color blind, like he was, from having problems. In his previous job, he had a hard time with the red and green colors.

He was so grateful that I didn't have the heart to tell him that I had used traffic signs just because I had thought it was a clever idea...

By Anonymous Nathan T. Freeman, at 8:04 AM  

This is a good example of where the platform really fails us, y'know.

For one thing, the model for alt-text for images in Notes is basically missing. There's a few fake pieces, like the ability to get hover text in this situation for the RESOURCE NAME for the images -- but that's a sad hack at this point.

Second, accessibility conditions should be a defined mode of operation IMO. Whether I'm coming in through a rich client or a browser, special accessibility considerations should be as programatically defined as the user's default language or timezone. And that should allow me to use tools like hide-whens or to programatically reveal text-versions of columns. Or even better, to allow the user to say "I have trouble with icons in views/actions -- always show me the alt-text instead."

You can do this with browsers fairly easily today. It's a weakness of IBM's rich platform that they need to address, and to be perfectly honest, I'm not going to build second-rate designs (and c'mon, both your example views look torturous!) unless a customer has specific demands for it.

IBM falls into this trap with their own designs all the time. How many obvious interface tunes did we miss out on in the 8 development cycle because they had "accessibility issues" with something like moving a menu item to the context menu?

So you're inside the walls now, Chris. Go get 'em to do this stuff right! :-D

By Blogger Keil, at 6:03 PM  

Come on Nathan, second-rate designs? I'm not disagreeing with your assessment of the accessibility options available to us in the Notes Client (you're at an entirely differnt level from me in your thinking there), but keeping accessiblity in mind as you develop doesn't make things second-rate. To make an app more color blind friendly is often a matter of simple choices while you're builing your app. While making a Notes app accessible for the legally blind may be somewhat more difficult in the Notes Client, why not keep the simple tips (like Chris's) in mind while we build our apps?
And picking on Chris' examples? I've seen some of your quick sample work. But I guess your blog isn't called Interface Matters ;).

By Blogger Nate, at 7:28 AM  

LOL. Keil, I'd like to think Chris and I are close enough that we can tease each other once in a while.

And I'm not saying designing for accessibility automatically means second-rate. I'm just saying that the intersection of accessibility and platform limitations is often used as the justification for second rate designs.

Maybe that tendency leaves a sour taste in my mouth about accessibility in general.

Post a Comment

Links to this post:

Create a Link

<< Home