AskTog: Interaction Design Solutions for the Real World
 
Interaction Design Section   Living Section   About Bruce Tognazzini

AskTog, May 2009

Inclusive Design, Part 2

How to Achieve Inclusive Design

In Part One, I argued that accessibility should not focus just on the needs of the profoundly disabled, that well-crafted solutions can be of service to all. This new approach is called, “inclusive design” and it starts with organization.

Belorussian translation: http://webhostingrating.com/libs/inclusive-design-part2-be

Team Approach

Accessibility is not something to be left to specialists hired to clean up our mess at the end. It should be a priority of the entire development team from the beginning. Yes, companies should definitely have accessibility people on-board, but they should act as much as educators and coaches as designers. Everyone on the development team must be aware of and responsive to the full spectrum of identified users if your product is to sell to the widest possible audience. That’s the only way to achieve inclusive design.

One way to ensure everyone understands is to hire people with disabilities. Not only will they take an active part in inclusive design, but, as team members get to know them, the team members will find that they naturally begin to address their new brethrens’ needs: It’s natural for people to take care of their own.

Brainstorming

Inclusive design need not cost a lot of money, maybe none at all, and you can create compelling arguments that it will make your company money, just as it made OXO money with their Good Grips line of kitchen products, as I discussed in Part One. The biggest obstruction, then, is not resources, but mindset. You need to get your development team(s) thinking in a new way.

Set up a brainstorming session to consider how to incorporate inclusive design in your product lifecycle. Bring in not only the existing team, but one or more accessibility experts, including someone who has actually experienced a significant disability. Keep it free-form at the beginning by just creating lists of what kinds of people may use your product or service, including lists of strengths, limitations, likes, dislikes, etc. Also create lists of where they might use it, and what kinds of tasks they will want to accomplish.

Next, you can take the group through an analysis of how your current product or service fits the needs of the listed users today before launching into ideas that could both make it easier for people with significant disabilities to use the product, as well as making it easier for people with, in effect, temporary disabilities. (A temporary disability might be the inability to use an ASCII keyboard when driving a car at 60mph/100kmph.)

As the group considers the full range of expected users and environments, you'll see almost a magical shift in their thinking, and the ideas will flow.

One Inclusive Interface or Multiple Interfaces?

Your goal should be for the group to generate solutions that require only one inclusive interface, accessible to the widest range of users possible. The products I discussed in Part One, such as Good Grips from OXO and SimpleHuman's household products exemplify this.

Often, however, a single interface that solves all problems simply isn’t possible. For example, the keypad on a cellphone is a great input device when you’re not driving. Voice command tends to be slower and less accurate, and you sound like a fool standing in a store, for example, trying to enter a phone number by saying, “eight zero zero four two back BACK two BACK BACK! I said 'TWO,' you blooming idiot!...” However, when you’re speeding down the road, already trying to steer and eat at the same time, voice command can literally save your life.

Even in the most stable expected environments, parallel interfaces may be the right solution. For example, with traditional office applications, creating a parallel keyboard interface to the primary mouse interface is often the best solution for broadening the range of users your product will support. It is a particularly good approach for people with severe visual limitations because all targets are in a stable, predictable location. (Voice is also a good approach.)

Any such parallel interfaces, however, should always augment, not replace, the interface that is customary and comfortable. Two hazards to be aware of: Engineers, contrary to almost everyone else on earth, prefer keyboards, and working on esoteric interfaces, like voice, can be more fun. The lists of users you developed early in the brainstorming session will help keep people focussed on making the interface inclusive for everyone, not just the people in the room.

Work with Marketing to Sell the Design

After the brainstorm is over, and you’ve come up with a solid proposal for a redesign, it is time to sell it. Meet with your marketing people and have them help you craft a case that covers how much inclusive design will impact the project in terms of resources and schedules vs. how many more people you will attract to the end result. Come up with dollar figures and see if they come out in your favor. (MBAs in the USA, in particular, have been trained that the only thing that matters is making as much money as possible in the next 90 days.)

In the past, so often our only successful argument has been that it will cost a lot less money to do the right thing than to get sued. However, going for inclusive design, rather than the usual spotty approach of adding features only for people with profound disabilities, will often truly end up making money, sometimes big money. If your designs are inspired, you’ll be able to make that case, and your company will take a new direction with surprisingly little prodding.

Iinclusive design is really a mindset, rather than a separate set of design principles. As the following case studies will illustrate, if you just start with the simple exercise I suggested of listing and discussing the range of users and the range of environments they may encounter, you will automatically begin to make choices that will be attractive to all.

Learn from these companies, and present these case studies as evidence of the importance of launching your own inclusive-design effort.

Case Study: Sony Betamax Surprise: "Logic" Can’t Replace User Observation

By the early 1970s, Sony was offering raised symbols on their audio tape player piano-key-style keyboards, so that people who were blind could feel their way among the keys. This was an accessibility feature aimed at a very specific group of the disabled, if available to all.

In 1975, Sony released the Betamax VCR. It, like the audio tape players, had a series of piano-style keys labelled play, rewind, fast forward, etc. However, it didn’t have the raised symbols. Duh! People who are blind don’t use Video Cassette Recorders!

All of a sudden, experienced Sony users found themselves repeatedly pressing the wrong keys on their new machines. They didn’t even understand what was happening. They had never made these mistakes with their Sony audio players.

Guess what? Everyone had been making good use of the raised symbols on the Sony keys, including those with perfect vision. Not only did the raised symbols help in darkened rooms, they helped with the lights on, because people using VCR keys are looking at the screen to judge the results, not at the keys they're pressing.

The lesson? Before you drop a feature because people with a particular class of disabilities will not be attracted to a new product, observe experienced fully-able users of existing products and find out if they also use the feature.

Case Study: Apple Zoom: Penalty of a Focus So Tight It Excludes Almost Everyone

When Apple first installed accessibility features on the Mac, a nice one they came up with was Zoom. With the option once enabled in System Preferences, pressing Command-Option-+ anywhere at any time will enlarge the area of the screen around the mouse pointer. Pressing it repeatedly makes it get progressively larger, and pressing the minus key shrinks it down.

Zoom would have been a really nice occasional feature for everyone except for one fatal flaw. In order to communicate to people with profound sight limitations exactly what portion of the screen would be Zoomed, they drew a large black rectangle reflecting the edges of the Zoom region (the “preview rectangle”).

This rectangle was a godsend to my friends with limited vision, but it drove normally-sighted people crazy, and they would turn off the option as quickly as they turned it on.

Years later, someone finally made the rectangle an option, and now it is a really nice for people within the range of "normal" vision to be able to instantly Zoom anything by just putting the mouse over it and doing a keypress. It is now an excellent example of inclusive design.

(Zoom is located on the Universal Access panel within System Preferences, aka, the Control Panel.)

Case Study: Dish Network DVRs vs. Amazon Kindles: The Payoff for Identifying Your Users Before Coding

Dish Network is a large satellite direct-broadcast TV provider in the US. They, like most providers, offer a system called "closed captioning." The "captions" are subtitles, and "closed captioning" is a system that allows the user to control whether or not the subtitles appear.

Dish Network's model of disabilities appears binary: Either people are deaf, or they are not. If they’re deaf, they’re going to need subtitles all the time. If not, they’re never going to need them. Deaf people, tragically, apparently all live alone, so there would never be a time when someone else in their houshold would want to watch TV without annoying text covering a significant portion of the screen.

Based on such falacious assumptions, it is not completely unreasonable to require, as Dish Network does, that a user press the remote control buttons 15 times while navigating through four levels of menus to accomplish what Dish Network assumes is the one-time task of turning on closed captions.

The reality is, though, that the vast majority of people with hearing loss are only slightly hard of hearing, so, with most dialog, they need no help. For them to have to go through 30 button pushes (15 on, 15 off) every time they miss a single phrase of critical dialog is beyond unreasonable. Equally unreasonabe is to expect people who rarely need the captions to keep them on, cluttering up their screen, all the time.

If Dish Network had thought through the problem before coding, they would have identified not only the entire spectrum of hearing loss, from slight to total, but considered the needs of people with perfect hearing who also might benefit from closed captioning, from those struggling to understand a non-native language, a task made easier when they can both see and hear the words, to those struggling not to wake up their POSSLQ or parents.

They might have even considered that closed captioning can allow a person to keep watching a show on television while, for example, their companion talks on the phone or listens to music, making good use of the feature even though they have perfect, unobstructed hearing.

(Closed captioning itself is another example of a technology aimed at a specific disabled population that offers advantage to a broad spectrum, depending on circumstances. Even non-humans, e. g., computers now take advantage of it, handily capturing transcripts of TV shows.)

Kindle took the opposite approach to Dish. They considered the full spectrum of readers, as well as the environments in which those readers might find themselves. When they enabled the user to change font sizes, they didn’t hide the option away deep in the menu system. Instead, it is triggered by a key right on the front of the device that then enables users to dial in exactly the text size they want.

Kindle readers with severe reading disabilities can quickly and permanently shift font sizes up to fit their needs, but so can people over 40 who managed to lose their reading glasses while boarding an aircraft this morning for a six-hour flight. So can readers who have been thrust into an unexpected state of disability, such as travelers who find themselves with a bedside lamp sporting a 10 watt incandescent bulb.

Some readers run their Kindle’s text size up and down several times in a single day as they move from sunlight to shadow or as the hours pass and their eyes grow tired.

Amazon even considered readers who climb behind the wheel of a car and can no longer read at all: They are as if totally blind. Under such circumstances, their Kindle will read to them (as long as the author or publisher of the book is not trying to gouge the readers for a bunch of extra money for that right).

Instead of Dish Network’s binary approach to accessibility—either you’re deaf or you’re not—the Kindle designers considered how variable text size could be of use to a wide spectrum of people and designed accordingly.

Both companies had to stand the expense of fully implementing their feature. The difference is really one of attitude: Because Kindle embraced inclusive design, they made their feature easy to access. Dish just glued a feature they considered of use "only to those there deaf people" onto their existing interface, hiding it thoroughly in the process—after all, how many deaf people are there?

Amazon's return on investment was high; Dish's was not. Attitude and approach made the difference.

(Attitude, of course, is not enough by itself. As reader Andrew McDaniel points out, while you can change the size of Kindle's book text easily, you can't change the size of the dictionary definitions at all. Attitude must be coupled with the resources to carry out a complete solution.)

Inclusive design is something we need to think about all the time. We all need to take a refresher course in accessibility by spending time with people with differing abilities so we get a sense of what it feels like to be standing—or sitting—in their shoes.

Yes, if you go down the path toward inclusive design, you will be helping out individuals who need and deserve our support, but you will also, with proper design, be helping everyone else who will experience your work, and you just might be helping your future self for, as I quoted at the beginning of these articles, it’s not whether you will suffer from a disability during the course of your life, it’s when.

 

Join my intensive (and fun!) lecture/ workshop course. Sign up now!

Interaction Design course: Go from zero to interaction designer in just three days.

You may be coming in cold from engineering or graphic design. You may already be an interaction designer wanting to "fills in the blanks," establishing a more solid theoretical and practical base. I've aimed this course at all of you, covering the needs of both individual contributors and managers.

Join me as I teach the Apple method and show you how to not only organize for and come up with successful designs, but sell them to engineering and upper management.

It's intensive, yes: A one-semester-equivalent with a strong, real-world bias. However, we have a lot of fun along the way, and you'll leave having worked with a team to design and build a complete project, so you will have not only learned, but experienced everything taught.

User Experience Conference Website There's more than my course at an NN/g conference. You'll find a breadth of other specialized courses and networking opportunities that will put you and your company at the leading edge of the design curve.



Have a comment about this article? Send a message to Tog.

Previous AskTog Columns >


Don't miss the next action-packed column!
Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com.

return to top

---
 
Contact Us:  Bruce Tognazzini
 
Copyright Bruce Tognazzini.  All Rights Reserved