Designing for Accessibility

[ LiB ]

Unfortunately, designing for users with reduced abilities in such areas as motor skills, vision, and hearing is considered only as an afterthought. The best time to address accessibility is early and oftenthat is, when you plan as well as while you're building. This section points to issues you should address while building and discusses how best to address them.

General Issues

By the way, access is not an all-or-none situation. For example, vision disabilities range from blindness to low vision to color blindness. And sometimes people are only temporarily disabled. It all boils down to the, perhaps surprising, fact that making your app more accessible will also make it more usable.

The primary limits are vision (including clarity in colors and detail), motor skills (such as using a mouse, which some people can't), and reduced hearing. The easy way to approach all of these is to recognize and avoid times when critical content is only available through one sense. If you play an audio message "click the spacebar when you're done," for example, you should repeat it with onscreen text. Most likely, however, you'll find countless cases where you only use visual clues including text for important information. Ultimately, these folks need the text read to them and images described. Luckily you don't have to provide all that audio yourself. Instead, you can just make the text and descriptions available to devices that support Microsoft Active Accessibility (MSAA) otherwise known as screen readers.

Vision

I guess the good news is that Flash automatically provides text descriptions to screen readers of your buttons , clips, dynamic text, and input text. It also exposes your static text so that it too is readable. Unfortunately, if you've moved a movie clip off stage, you probably don't want the screen reader to describe it to the user . Ultimately you'll want to take the initiative to describe your own clips, hide specific ones, and turn on and off the descriptions using ActionScript when necessary.

Here's a quick overview. In the Accessibility panel, you can select buttons, clips, and dynamic or input text and modify their respective accessibility settings. In fact, if you have nothing selected, the panel reflects your movie's accessibility settings (see Figure 2.5). The two primary ways to use the panel is to either exclude an item from being exposed (by unchecking Make Accessible) or to override the automatic naming feature by specifying a name or description. In addition, because buttons, clips, and input text are interactive, you can have their tab index set here as well as a shortcut defined (such as Ctrl+1). (You need to write additional ActionScript to respond to the keyboard shortcuts you specifyall you're doing here is telling the users how they're supposed to access the field or button.)

Figure 2.5. Global Accessibility settings are visible when nothing is selected.

Manually selecting and setting every object onstage is not the only way to override the automatic naming features. You can do it all with script. Naturally, every object you intend to affect needs an instance name, but from there you can set name, description, and tab index properties using _accProps (as described next ). Also, you can take control of tabbing and selections through the Key listeners and the Selection object. Here are the basics. During runtime, you can effectively make changes to the Accessibility panel's settings using script.

You create an _accProps object, set a few properties, and then use Accessibility.updateProperties() to invoke the changes. Inside the _accProps object, there are expected property names that match the Accessibility panel's fields. Here's an example of how you can re-create the manual settings shown in Figure 2.6, but by using the following script.

Figure 2.6. Making settings in the Accessibility panel is manual, but a script can do it automatically.

 myButton._accProps=new Object(); myButton._accProps.silent = false; myButton._accProps.name = "the name"; myButton._accProps.description = "the description"; myButton._accProps.shortcut = "Ctrl+1"; myButton._accProps.tabIndex = 1; Accessibility.updateProperties(); 

You can easily match the properties to the corresponding options in the figurebut notice Silent is the opposite of Make Accessible. In this case, we need a button with the instance name myButton . Had we been addressing a movie clip instance (or the main movie itselfby leaving off myButton ), the additional property forceSimple could be set to false in place of Make Child Objects Accessible (an option only available for clips).

Although the details of how to technically expose names to persons with limited visibility may seem involved, the real work is thinking of clear names. Incidentally, the name property should always be very short. The description is equivalent to the HTML longdesc property. Here you can write in explicit detailalthough do try to keep it concise .

Motor Skills

Ideally, users can use your app without much mousing around. Seriously, a mouse can be very difficult to operate , and there are several ways to design your app to account for this. First, avoid tiny buttons! If nothing else, make the hit state as large as possible, even if that means expanding beyond the button's borders. Also, if you find while testing that you click the wrong button or something, take it as a sign that you need to make it bigger. Sometimes it's even more than just the button's size that's a problem. Consider, for instance, a slider control like that in Figure 2.7. You can increase the hit state so that more than just the tiny box is clickable. But what happens when the user clicks the linenot the box? It would be nice if the box jumped to where the user clicked and automatically started dragging. The point here is that even if you're requiring a mouse, it doesn't mean you have to require the precision of a surgeon.

Figure 2.7. Tiny sliders are fine so long as you don't make them difficult to select.

Consider, too, that blind folks won't be able to use the mouse. So, although I've included the following discussion under motor skills, realize it applies to low vision, too. Taking control of the tab order (as opposed to letting Flash do it automatically) involves several related mechanisms. The first step is to set the tabIndex property of any particular object. The only catch is that in Flash Player 7 each movie clip has its own tab sequence. That is, two clips could both have fields with indexes 1, 2, and 3. While one clip was focused, you'd just cycle through its three fields; then when the other clip was focused, you'd cycle through its fields. To make a particular field receive focus (say, when tabbing out of the last field in one clip), you can use Selection.setFocus(clip.field) (replacing clip and field with the actual clip and field instance names). In addition, if you're using just one of the new UI components in your movie, the new Focus Manager steps in. Basically, this means you'll see a green glow on the currently focused objectwhich includes text, buttons, and any interactive component such as radio buttons, combo boxes, and so on.

Although setting focus is fairly simple, the hard part is figuring out when you want to set it. That is, trapping the event you want to use to trigger the change is a bit trickier. Generally, you want to look at Listeners for the Key object and the Selection object.

By the way, to test any keyboard controls you add, be sure to select Disable Keyboard Shortcuts from the Control menu (when you're doing a test movie). Otherwise Flash's built-in keyboard commands will override yours.

Hearing

The fact that some people may not be able to hear your app means that to make it more accessible you should provide captions. This not only means the entire transcript of narration needs to be available in readable form, but also a description of what's shown onscreen. This normally applies to video. Keep in mind that this means you need to describe anything onscreen for those visually impaired, too. I suppose a lot of RIAs have more to do with data than video presentations, but it can still come up.

When you need to caption a piece of timed content (such as a video), realize that you need to figure out the sync points "offline." That is, during production you might build a mini-app that enables you to watch the video and click a button every time the next line of text should appear. You need to record those clicks and use that time information during playback. For a video inside a movie clip, it's easy to tie the sync points to frame numbers in the clip. If you're playing external FLVs, you'll want to check out the send() method (covered in Chapter 8, "Foundation Communication Server"), because it embeds events right into a video. Finally, straight audio has a position property that you can use with the Sound object.

Throughout this section on accessibility, you might have thought terms such as low vision were some attempt to be politically correct. Although I do think it's important to be sensitive, there are all sorts of disabilities that range from mild to extreme. In fact, provided you live long enough, you will experience some limits. In any event, the best way to approach accessibility is to make your app more usable.

Note

Third-Party Accessibility Tools

If you do plan to create a fully accessible app or even just need to do a lot of captioning of audio or video, you should check out two products made for Flash MX 2004. HiSoftware has two products that plug in to Flash. HiCaption includes both a production tool for adding captions and the code needed to play back those captions inside your Flash app. The other product, AccVerify/AccRepair, is a test bed application that you run on your Flash app. It scans your Flash document and will report instances such as places where you haven't provided text equivalents or you've created a funky tab order. Check out both products at www.hisoftware.com/macromedia/.

[ LiB ]