Focusing on Accessibility Barriers

Gregory C. Lowney

November 1, 1995

Everyone wants his or her product to attract as many users as possible. But many programs unintentionally put up barriers that prevent some customers from employing them enjoyably or efficiently—even, in some cases, making them impossible to use. This problem is most pronounced for computer users who have disabilities.

Software design decisions can either make it easy for these users or drive them to competitive products. Your business customers may standardize on a competitive product even if they employ relatively few people with disabilities, and you could even put some of your customers in violation of anti-discrimination laws. When your product is friendly for people with disabilities, it is also addressing the needs of their friends, family, coworkers, and employers.

This new column on accessibility discusses how you can identify barriers in your designs, and how, with very little work, you can make your products more accessible and more usable.

An increasing number of people are interacting with applications by using software assistants, utilities that filter or automate different types of interaction. For example, voice-input utilities are used by executives, doctors, machinists, and others who need to operate the computer while their hands are busy. Such utilities are a necessity for people whose disabilities make it difficult for them to use the mouse, keyboard, or display. Among these are people with repetitive stress injury (RSI), one of the fastest-growing categories of disability. Other people use keyboard macro packages, word-prediction packages that speed typing, screen-magnification utilities to relieve eyestrain or compensate for low vision, or even audio software that describes the contents of the screen to make it accessible to people who are blind or people accessing their computer over a telephone. Making sure an application is compatible with accessibility aids is a key factor in making it accessible.

Indicating the user's point of focus

Many accessibility aids need to identify the "focus point," where the user is working. For example, a blind-access utility must describe the text or object the user is working on, and a screen-magnification utility pans to enlarge whatever is at that point on the screen. Other utilities may move pop-up windows so they avoid covering "where the action is."

Sometimes it's easy for a utility to determine this location; the operating system provides it when moving the focus between windows, menus, or standard controls. The difficulty comes when an application uses a private method of indicating the visual focus within its window, such as highlighting a cell in a spreadsheet, an icon, or a windowless custom control. In these cases, to be accessible, the application must make its focus location available to other programs in the system; the convention for doing this is to move the system caret.

Moving the system caret

The system caret is the blinking vertical bar that's seen when you're editing text, but it can be placed anywhere on the screen and made any shape or size. It can even be made invisible—it can be moved to indicate the focus region to programs without disturbing what the user sees on the screen.

Doing this is easy: simply call CreateCaret to set the caret's size and shape, and SetCaretPos to move it to wherever you're drawing the visual focus indicator (the highlighted cell, icon, button, and so on). Remember, it's present but invisible unless you explicitly say otherwise.

Applications should only display focus and selection indicators when they're the active window. When you lose activation, remove the visual indicator and also call DestroyCaret to inform other programs. (For Win32-based applications, this is not strictly necessary, but is still good practice.)

Where is the keyboard focus?

Sometimes it seems hard to decide what you should indicate as the focus location. Extended and discontiguous selection often confuse the issue, but the real answer is pretty simple: The keyboard focus location should be considered independent of selection, even if your application normally links the two.

The following examples may clarify the distinction and help you learn to identify and indicate the keyboard focus location in your own application:

• Insertion bars in text. When the user is moving an insertion point within text, it's usually drawn with the real system caret. If the application chooses to draw its own insertion point, it should still move the system caret invisibly, tracking the location of the visible insertion bar.

• Extended text selection. When you make an extended selection, one end of the selection is always the "active" or moving end, and that's the actual location of the keyboard focus. For example, starting with the insertion bar in an edit control, hold down the SHIFT key while pressing the right arrow twice; you now have three characters selected. The end where you started is the "anchor," or stationary end; at the right you should see the flashing caret marking the active end. If you hold down SHIFT and press another arrow key, it's the active end that moves; that's where the system caret should be placed. Don't forget to display a visible insertion bar at the active end, because that's useful feedback for all users.

• On graphic objects. When a user moves the keyboard focus to a graphic object, such as an icon or a bitmap, an application should place the system caret invisibly over the same object so that the caret's rectangle covers the entire image. If there's an adjacent label, the caret should cover that as well.

• Within graphic objects. Sometimes an application uses a single bitmap to represent several objects, such as a group of graphical buttons. Such applications usually indicate the focus by highlighting a portion of the bitmap, or drawing a dotted rectangle over it, or even moving the mouse pointer. In these cases it should also place the system caret, invisibly, over the region of the bitmap that corresponds with the "hot spot" or object being referenced.

• Simple controls. If an application is drawing simple custom controls, such as a custom push button, the keyboard focus is associated with the entire control, so the entire control should be covered by the system caret. (This is necessary only for windowless custom controls; if the control is a window, that window takes the keyboard focus, so it's not necessary to identify it using the system caret.)

• Complex controls. A complex or composite control, such as a list box, can place the focus on individual elements within the larger control. In this case, use the system caret to indicate the area of the particular item that has the focus. Even though the application might think of the collection of items as a single control, they should be treated as separate control elements when identifying them to external components.

• Spreadsheets. When navigating within a spreadsheet, one normally puts the focus on an entire cell, rather than on content within the cell. Often this is indicated by giving the cell a bold border; the application should place the system caret over the entire cell. If the user begins editing the contents of a cell, indicate the focus appropriately for the content text or graphics.

• Discontiguous selection. Discontiguous selection is usually supported among discrete items, rather than in text. There's always one item that has the keyboard focus or was most recently clicked with the mouse, and that object should be covered by the system caret. To see an example, select an item in a folder or in File Manager, then hold down the CTRL key while pressing arrow keys to move the focus rectangle to a file that isn't part of the selection.

• Mouse-only objects. While applications should provide keyboard access to all their functionality, sometimes you have objects that can only be manipulated or selected with the mouse. In this case, treat the object when it's selected as if it received the keyboard focus, and use the system caret to indicate it appropriately. Of course, if the real keyboard focus is moved, follow it, since the mouse-only object is no longer the object of the user's attention.

Does it work?

If you do it right, moving the system caret is one of the simplest and most effective ways to make your application compatible with a wide range of accessibility aids. You can test it by using the CARET and CARET32 tools that are planned for an upcoming release of the Microsoft Development Library. These tools will show you where the system caret is at all times. Future releases will provide more guidelines on accessible software design, and possibly even demonstration versions of commercial utilities that rely on this technique.

We recognize that this method is not effective for some multithreaded applications, and under Win32 it's not as easy for accessibility aids to track. So, in the works is a new standard, called OLE Accessibility, that will provide a more sophisticated mechanism for publishing information about your focus and selection. Watch for it in future columns on accessibility.

Greg Lowney founded and manages Microsoft's Accessibility and Disabilities Group. Previously, he was senior program manager responsible for the Windows 3.1 core components.