The Fundamentals of Accessibility Development

You've probably heard about screen readers for people who are blind and voice activation for people with mobility limitations. Even if you're not designing software specifically to work with these types of hardware, the information in this chapter still applies to you as a developer. Any application you develop with Visual Basic should have certain features that make it accessible. The following sections describe some of the more basic features to consider when developing accessible applications and how to implement those features.

Using the Keyboard

One of the most important considerations in the design of an application is how user input will be captured. In graphical user interfaces (GUIs), application developers often tend to focus on capturing input from the mouse. A user typically employs the mouse to perform actions such as clicking buttons, dragging and dropping files and information, and highlighting data. The mouse is a very useful tool and the most convenient method of accessing features of a GUI application.

As a developer, you painstakingly design a user interface that has a lot of buttons, menu options, drop-down lists, and other such features to make sure all the information your application is presenting is a simple mouse-click away. You might spend months working on such an application getting it to look and function just right.

Now it's time for the end user to run your application. As an example, run the NoKeyboard sample application included on the companion CD. (See Figure 16-1.) You'll find that it's functional and simple to use. Now try using it without the mouse. You've just found yourself in a predicament many people find themselves in every day. A number of disabilities can make it difficult or impossible to use a mouse. Quite often, experienced computer users and skilled typists simply prefer to use the keyboard—it can be quicker and more convenient than using the mouse. Whatever the reason, because your application relies so heavily on the mouse, it's totally useless or extremely inconvenient for a very large number of people.

Figure 16-1 Sample application with limited keyboard interface

What can you do to remedy this situation? You must design keyboard access into all your applications and interfaces. Try running the Keyboard sample. You'll notice it looks very similar to the NoKeyboard sample, but there is one big difference: every action you can perform with the mouse you can also perform using the keyboard. Let's go over some of the changes that were made to the NoKeyboard sample to produce the Keyboard sample.

NOTE

---

The samples for this chapter that you'll find on the companion CD are to demonstrate user interface features only. You won't find a lot of functionality behind the samples that doesn't relate to displaying and using the interface.

Menu layout

One difference between the Keyboard sample and the NoKeyboard sample is the menu layout—the menu items are in a different order. If you've ever worked in product support, you know you spend a lot of time explaining things that can be found in the online Help. So why not call the user's attention to the Help option by putting it first on the menu? Because that's not where the user is used to finding it. Windows applications have been designed according to standards that allow users to move seamlessly from one application to the next. You might not agree with all the standards, but for your users' sake, don't try to change them. Menu order is especially important for people with visual impairments who expect to find certain interface elements in certain places, and searching around an interface can be a time-consuming and frustrating chore.

Key combinations

Shortcuts are an important part of interface design. All menu options should have an access key. An access key appears as an underlined character in the option name, indicating pressing that key activates that option. Pay careful attention to the keys you are assigning—every key must be unique within each menu or submenu. If your menu includes options that you expect to be used frequently, providing hotkeys (such as Ctrl+S for File Save), also known as accelerator keys, can save the user a lot of time. The user can perform the action without continually activating the menu. Look at the difference between the menus in Figure 16-2.

Figure 16-2 Menus from the NoKeyboard sample (left) and the Keyboard sample (right)

If you're providing functions that are common to most applications, use the most common naming standards and key combinations, such as File Open and Ctrl+O for opening a file. I once had to work with software that had menus you would expect to see, but the keyboard interface drove me crazy. Instead of exiting an application by selecting Alt+F (for the File menu) and then X (for Exit), the interface was designed to select Alt+F and then E. You'd be surprised to know just how many times I hit Alt+F and then X and the computer just beeped at me. Your users will spend a lot less time learning and remembering how to use your application if you give them something they're familiar with.

Navigation

Navigation is the means by which the user moves from one part of a window or dialog box to another, such as from one text box to another. Keyboard navigation is usually accomplished through use of the Tab key and the arrow keys. Setting a logical navigation order makes an application much easier to use than if pressing the Tab key or an arrow key takes the user to unpredictable places. When you create a form in Visual Basic, the tab order of controls on the form is set automatically according to the order in which you place the controls on the form. This can easily make for a strange tab order if you've rearranged the controls or deleted and then added controls. For example, the tab order shown in Figure 16-3 will confuse or simply annoy users. The tab order in Figure 16-4 is much more intuitive. When your user interface is final, you should determine a logical tab order, and then set the TabIndex property of each control according to that order (starting with 0).

NOTE

---

The MSDN Library includes a sample application called TabOrder. You can use this add-in in your Visual Basic environment to set the tab order of your form without setting each individual TabIndex property yourself.

Figure 16-3 Confusing tab order

Figure 16-4 Logical tab order

Navigation order is a common convenience for all users, but is especially important for users who don't or can't use the mouse. For example, someone who uses a screen reader will tab through the controls on a form to find out what each control does. Logical navigation makes the interface much easier to use and understand.

Colors

Have you ever walked through an office building and glanced at the computer monitors people are using? If you have, you've probably noticed the great variance in color schemes people set to display on their monitors. Many times I've looked at someone's monitor and wondered how anyone could look at that horrible color combination all day. But I'm just talking about personal preference, right? What does that have to do with accessibility programming?

Color schemes are an integral part of programming. In Visual Basic, you can assign colors to your interface elements easily enough by using control properties. You can set controls to different colors depending on the options the user selects. You can use colors to convey information to the user, and to make your application exciting and interesting.

Now remember those awful color combinations. You can't be sure everyone will enjoy the colors you've chosen for your application. What's more, some of the color schemes you see weren't set because people wanted to look at something pleasing to the eye, they were set so the user could clearly see everything on the screen. An example of such a color combination would be the High Contrast color combination. This setting is available both from the Display Properties and from Accessibility Options, both available from the Control Panel. See the section "High contrast" later in this chapter for further information on this setting.

Color blindness and other visual impairments affect a lot of people in many different ways. You can't accurately guess what color combination every computer user is going to be able to see on the screen. But you can design your application to allow each user to set his or her own colors, avoiding the problem altogether. You can do this by setting the colors in your application based on the system settings the user defined on the Display Properties property sheet. Visual Basic includes a set of constants that represent system colors, such as vbWindowBackground and vbTitleBarText. We'll be using some of these constants in our color sample applications.

Background patterns

Sometimes it's nice to have an image or a pattern in the background of an application, an image of your company logo, for instance. While this can look nice and seem unobtrusive, a background image can cause a lot of problems for your users. It makes the screen busy, so people with cognitive disabilities can have difficulties focusing on the actual information provided on the screen. Background images can also cause difficulties for users who are color blind, and even those with low vision, because text and labels often end up on top of a busy background. As an example, let's look at the FullColor sample, shown in Figure 16-5.

The background image in this case is a picture of Half Dome at Yosemite National Park. It's very pretty and is relevant to the topic of hiking addressed by the application. However, if you're not in high color mode the first thing you'll notice is that this picture is quite ugly. If you are in high color mode and can see all the colors of the picture, you'll notice that the screen is very busy, too busy for some users. The best solution to this problem is to provide the user with a means of turning off the background image. The ColorOpt sample gives the user an Options menu with a Background menu item that allows the user to turn the background image on and off. This is done with a call such as the following:

Figure 16-5 FullColor sample showing a detailed background image

 Const IDB_BACKGROUND As Long = 101 . . . Private Sub ChangeBackground(ByVal bRemove As Boolean)     If Not bRemove Then             ' Turn the background off         Set frmHiking.Picture = LoadPicture()         frmHiking.BackColor = vbWindowBackground     Else                            ' Turn the background on         Set frmHiking.Picture = LoadResPicture(IDB_BACKGROUND, vbResBitmap)     End If End Sub 

Notice the BackColor setting. The vbWindowBackground constant designates the Windows system setting for a window background. By using this constant the application displays the window background color set by the user in his or her Display options. You can find all the color constants in Visual Basic's online Help under Reference/Language Reference/Constants/Core Language Constants/Color Constants.

Color coding

The FullColor sample has been designed to give the user a choice between day hiking and overnight hiking and to suggest equipment that should be carried on the selected hike. A simple way to do this is to color code the options. To make the options visible on the picture background, I chose a green color (&HFF00&) from my system palette at design time as the Required color, and a yellow color (&HFFFF&) as the Optional color.

NOTE

---

Colors are identified by hexadecimal values that represent the intensity of the component colors red, green, and blue. The component values range in intensity from 00 (lowest) to FF (highest). For example, the hexadecimal value for pure green is FF00, or 00FF00—00 for red, FF for green, and 00 for blue. Likewise, pure red would be defined as FF0000.

When you set your colors at design time, you can use the Properties window to set the foreground and background colors for controls and forms using the drop-down palette shown here:

If you select a color from the palette, you'll be selecting from your current system palette, as I did. If you're running in high color, you could be choosing colors that someone running in 256-color or 16-color mode doesn't have. Windows will do its best to substitute, but often the results aren't what you'd like. For now, though, we have a nice application with a pretty background that conveys the information we need. Unless, of course, the user can't read it. The green and yellow I've chosen might be invisible or indistinguishable to someone who is colorblind. These colors might also not be visible to a user who has turned the background picture off, depending on what their default window background color is.

The first solution to using the green and yellow colors is to use system colors, as we did with the window background. For the ColorOpt sample I've set the Required color to vbHighlight and the Optional color to vbWindowText. However, even these colors aren't enough to distinguish the different options. You should never rely on color alone to convey information. Our final solution is in the ColorOpt2 sample, shown here:

In this sample we're still using the colors to differentiate the options, but we've changed from labels to check boxes. Now the Required options have check marks next to them as another way to convey the information to the user. Another solution, which you'll see only if you have a screen reader device connected to your machine, is the changing of the check box captions depending on the option selected. If the user has a screen reader connected to his or her machine, you want to turn off the background image and give a non-graphical indication of the options. So in addition to the check boxes, if the ColorOpt2 sample detects a screen reader device it will add text to each caption indicating whether the option is required. See the section "Screen readers" later in this chapter for information on determining whether a screen reader device is present.

Sound

Computers make noise. I sometimes give my PC a good thunk to reduce the noise. But most of the noise comes from the speakers, and most of the time it occurs for a good reason.

Why applications make noise

The primary uses of sound in applications can be placed into three categories:

• Decoration

• Alert to information on the screen

• Alert to information not on the screen

An example of sound as decoration would be background music that plays while an application is open. This use of sound doesn't affect accessibility, as long as it doesn't interfere with the alert sounds or screen readers.

An alert to information on the screen would be sounding a beep to draw the user's attention to a visual error message. An example of an alert to information not on the screen would be the beep that sounds when the user clicks an inactive area of the application.

When is sound a factor?

Sound can be a great benefit for people who are blind or have low vision. Sounds provide an indication that something has happened on the screen that requires attention. On the other hand, sound is of no benefit at all to someone who is deaf or hard of hearing. Even for users who don't have disabilities, there are times when they can't hear or don't want to hear sounds. If you're working in a factory, you probably won't hear much coming from the computer. If you're in a library, you don't want your computer beeping and talking. All these situations point out the need for visual cues to work in conjunction with sounds to inform the user of anything important going on in an application.

Audio and visual cues together

The number one rule in using sound in your application is to never use sound as the only means of communicating important information. You don't have to give visual indications of every sound all the time, but it should at least be an option. You could put a menu option in your applications that turns sounds within the application on or off, or an option to set whether visual cues will be displayed in conjunction with sounds.

When you supply a visual indication of a sound, make sure it's noticeable. One option is to use the FlashWindow function, explained later in this chapter. While FlashWindow is designed to provide a quick visual cue that something has happened, you might also want to consider using a visual indicator that remains on the screen for a certain amount of time or until the user dismisses it so that you're more likely to get their attention.

Closed captioning

I'm not going to go into the details of adding multimedia elements to your application. But if you do display audio/visual clips in your application, you should provide closed captioning. Closed captioning is the displaying of dialogue and sound effects in an audio clip as text on the screen, similar to subtitles. Microsoft has just developed a new technology called Synchronized Accessible Media Interchange (SAMI) format, designed specifically to provide closed captioning to multimedia software and Web applications. SAMI will be included as part of the Microsoft NetShow 3.0 (which replaces NetShow, DirectShow, and ActiveMovie) media player. You can also use the ShowSounds Accessibility option, described later, to determine whether you should turn on closed captioning.

Size

The size of a form, as well as the sizes of the objects and controls on that form, impacts users with low vision and mobility impairments. I find often that it's in the nature of a programmer to try to put as much information in one place as possible, but in terms of accessibility and general usability that's not always the best way to go. Here are a few sizing guidelines to follow when designing your user interface.

• Make sure the interface fits on a 640x480 pixel screen resolution. Users with low vision, and sometimes those just trying to avoid eye strain, keep their resolution at this highest point. Creating an interface larger than 640x480 pixels means part of your interface will be hidden and inaccessible to many users.

• Use the system settings to display standard elements. This is pretty simple in Visual Basic. When a user changes the system display settings (from the Control Panel Display properties) and applies those settings, your Visual Basic application will automatically pick up those changes. Try running one of the sample applications that contains a menu. With the sample still running, go to your Display properties and change the font size of the menu. When you click Apply, you'll see that the menu in your Visual Basic application has changed to the new settings. However, the size of the menu doesn't change the size of the form, so the menu might wrap on the form if you don't change the form size to accommodate the menu. You might also need to resize your controls at run time based on the changes to the system settings in order to make sure they're all still visible. See the discussion below on using the Size sample.

• Allow customized sizes. You can allow the user to customize certain properties at run time. For instance, you can allow the user to size a form, at which time you'd adjust the size and spacing of the controls in the Form_Resize event procedure. You can also include common dialog controls that allow the user to set the font sizes and styles specifically for your application. Again, you'll need to resize the form controls accordingly. (See the Size sample.)

• Make borders visible. Borders separating screen elements can make a user interface more intuitive, but only if the borders are visible to everyone. To determine an appropriate border size, you should call the GetSystemMetrics function, discussed later in this chapter, with the constant values that determine border width and height.

Size example

I've created an example to demonstrate how to dynamically size controls and allow the user to customize the look of an application. This sample application allows the user to size the form and set the font size for all the controls on the form. The form and the controls adjust to fit the changed settings. First let's take a look at the form in design mode.

I've kept this example simple by including only three controls—two labels and a text box—as well as a common dialog control. I've also added two menus: File and Options. The Options menu contains one menu item, Font. This item uses the common dialog control to display the Font dialog box, shown here.

By selecting the Font menu item, the user can set the font style and size for all the controls on the form. Let's take a look at the code that does this.

Private Sub mnuOptionsFont_Click()     Dim ctlControl As Control     ' Initialize the settings and display the Font dialog box.     With dlgCDialog1         .Flags = cdlCFBoth ' Display the screen and printer fonts.         .FontName = labLabel2.FontName         .FontSize = labLabel2.FontSize         .ShowFont     End With     On Error Resume Next     ' Run through all the controls, setting the font size and style     ' according to the user selections in the Font dialog box.     For Each ctlControl In frmSize.Controls         With ctlControl.Font             .Name = dlgCDialog1.FontName             .Size = dlgCDialog1.FontSize             .Bold = dlgCDialog1.FontBold             .Italic = dlgCDialog1.FontItalic             ' Set the heading size to be larger than the rest             ' of the controls.             If ctlControl.Name = labLabel1.Name Then                 .Size = .Size + 4             End If         End With         ' Resize the controls to fit the new font.         ctlControl.AutoSize = False         ctlControl.AutoSize = True     Next ctlControl End Sub 

The first thing we do is initialize the settings for the common dialog control. We set the Flags property to cdlCFBoth to indicate that we want the dialog box to display fonts that are available for both the screen and the printer. Next we initialize the font name and size to the current settings for the controls. We then call ShowFont to display the Font dialog box.

At this point execution of the Visual Basic routine pauses while the Font dialog box is displayed and the user selects his or her settings. When the user closes the dialog box, the application loops through the controls on the form and assigns the new settings to each one. The label that acts as the heading for the form should stand out from the rest of the controls, so I've increased the font size for that control.

NOTE

---

Some of the controls on a form might not support the Font property. To guard against any errors that might arise I've included the error statement On Error Resume Next to bypass these controls. Chapter 1 of this book warns against problems that can occur from using this statement. I've used it here for the sake of simplicity, but in your own programs you'll probably want to check the control type to make sure the control supports the given property, and use the error checking recommendations described in Chapter 1.

Looping through the controls and changing the settings isn't the final step. The font might now be too big for the controls that were created at design time. Maybe when you designed the controls you were sure to set the AutoSize property to True, thinking that would size the controls as needed. Unfortunately, the AutoSize property doesn't work like that. Each time the settings are changed, you need to set the AutoSize property to False to uninitialize it, then set it again to True so that the control will be resized.

We now have all the code in place so that the user can size the fonts in the application. But what happens if the controls aren't fully visible on the form anymore? Or if the user just wants to see more or less of the form? To accommodate these possibilities, we've made the form resizable. The user can make the form as big or as small as he or she wants (allowing for screen size). If we leave the controls as we placed them at design time, sizing the form smaller would cut off some controls, while sizing it bigger would leave the controls where they are and just show a lot of blank space on the form. We want the controls to move in proportion to the sizing of the form. For this to happen, the placement of the controls must be changed in the Form_Resize event procedure.

Private Sub Form_Resize()     Dim ctlControl     As Control     Dim nHalfWidth     As Integer     Dim nHalfWBuffered As Integer     Dim nHalfHeight    As Integer     Const BUFFER_AREA  As Integer = 100     nHalfWidth = ScaleWidth / 2     nHalfWBuffered = nHalfWidth _ BUFFER_AREA     nHalfHeight = ScaleHeight / 2     On Error Resume Next     For Each ctlControl In frmSize.Controls         With ctlControl             Select Case .Name                 Case "labLabel1"                     .Alignment = vbCenter                     .Width = ScaleWidth                     .Left = 0                     .Top = 0                 Case "labLabel2"                     .Width = nHalfWBuffered                     .Left = 0                     .Alignment = vbRightJustify                     .Top = nHalfHeight                 Case "txtText1"                     .Width = nHalfWBuffered                     .Left = nHalfWidth                     .Alignment = vbLeftJustify                     .Top = nHalfHeight             End Select         End With     Next ctlControl End Sub 

The Form_Resize event procedure is called every time the user sizes the form, as well as when the form is first displayed. For each of the controls on the form, we set the Width, Left, Alignment, and Top properties to determine where on the form the control will be placed. For example, we always want the form heading, labLabel1, to be centered on the form no matter what the size of the form is, so we've set the Alignment property to vbCenter. Because there are no other controls at the same vertical position as labLabel1, we can set the Width property to ScaleWidth, which is the width of the form. That also allows us to place the left edge of labLabel1 all the way to the left edge of the form, position 0. The heading will always be at the top of the form, so the Top property is also set to 0.

The other controls are sized in a similar manner. Because they are located side by side, they must share the width of the form (ScaleWidth / 2), and allow for some white space in between (- 100). Run the Size sample and try setting the fonts to different sizes and resizing the form to see the results.

Creating A Resource File

In the code sample shown above, you see calls to LoadPicture and LoadResPicture. The call to LoadPicture with an empty parameter list removes any picture that has been loaded. To put the picture back on the form, you could call LoadPicture with the filename of a picture (BMP, JPEG, and so on) as the parameter. However, it's more efficient to store your picture in a resource file and use LoadResPicture to load the picture from the resource file.

To create a resource file in Visual Basic, you first must add the Resource Editor add-in to your Visual Basic project. Select Add-In Manager from the Add-Ins menu to bring up the Add-In Manager dialog box. From the Available Add-Ins list, select VB 6 Resource Editor. Check the Loaded/Unloaded check box in the Load Behavior group and click OK. You'll now see the VB Resource Editor button, shown here, on the Standard toolbar.

Now that you've included the Resource Editor in your project, you can create a resource file and add the bitmap you're going to use as your background image. (You can also add text strings, icons, cursors, and custom resources to the resource file.) Click the VB Resource Editor button to open the Resource Editor window. Click the Add Bitmap button on the Resource Editor toolbar to open the Open A Bitmap File dialog box. Select the bitmap you want to include in your resource file and click Open. The bitmap is added to your resource file and assigned a resource ID that you will use as the first parameter in your call to LoadResPicture. Save the resource file.