Bounce Metronome Wiki- Bounce helps you keep time

Developing an application for blind users - accessibility issues for developers

From Bounce Metronome

Jump to: navigation, search

Here I'll share some thoughts about development of accessible applications for blind users based on my experience with Bounce Metronome.

Contents

Standard window controls

The easiest approach is to use the standard Windows controls as far as possible because they have accessibility already built in. Also especially to use dialogs and menus extensively as they are easy to navigate for blind users.

tab order

Then - to remember that a blind user has to read through all the controls in a window, and tab through them to get to the one you want. So it is important how the window is organized and how easy it is to get to a particular section of the window.

There the most important thing to pay attention to is the tab order, something which developers designing a window for visual use will often not think about at all.

For instance if you copy and paste a button from one dialog to another, even if the button goes into the middle of the window visually, the button will always go to the end of the tab order. You might not notice anything amiss because visually it looks just fine.

However, blind users when they navigate your window will navigate it in tab order, so the window can get very confusing for users of screen readers, after a fair amount of editing of this sort, if you don't pay careful attention to the tab order when you make or edit the dialog.

Keyboard shortcuts

The other main difference from normal Windows programming is that keyboard shortcuts are very important. Developers might not think about these at all and a few extra keyboard shortcuts can make all the difference to a blind user, especially if the control is frequently used.

These are easy to add to Windows programs with accelerators, and with the option to simply place an & before a letter to turn a check box, edit field etc into one accessible with a keyboard shortcut. So this is not a technical problem, it is more a matter of thinking through carefully what could be useful shortcuts. As a general guideline, if you use a control frequently, then it is likely to be useful to give it its own keyboard shortcut.

Test with screen readers

Then, you need to use a screen reader while testing and to try all the main screen readers if you can - Jaws, Window Eyes, Thunder, and now NVDA, and Narrator for anyone who doesn't have a "proper" screen reader installed. And listen to what blind users of your software say when they try it out. The most important ones are probably Jaws, Window Eyes, and now, NVDA.

They are easy to install and easy to get hold of.

The free ones in that list are:

  • Narrator (which you get to via Windows key + U)
  • NVDA
  • Thunder

The paid for ones both have demos that are useful for accessibility testing

  • Jaws - use for 40 minutes before you have to reboot.
  • Window Eyes - use for 30 minutes before you have to reboot.

If your application is reasonably debugged with the free screen readers, you can test remaining issues under Jaws and Window Eyes under demo mode - and don't need to reboot too frequently. So - when working on accessibility I have one of the free screen readers running just about all the time, and then run Jaws and Window Eyes from time to time (the two together add to a total of one hour and ten minutes of demo time).

These tests often turn up things you never thought of as issues when you worked on the design of your application.

If your application UI is quite simple, it might be worth doing a separate version for blind users

This is for the case of a fairly simple program, with a carefully designed graphical user interface that is hard to make accessible. The simplest approach might be to just have a complete alternative text based user interface for blind users using dialogs and menus throughout.

In the case of Bounce Metronome I have a separate completely text based version of the main window for blind users, also of the tempo dial (which clearly they can't use) and some other windows. In the main window I have a visible button, but textured to be invisible to sighted users, at the top of the window tab order, which takes you to the screen reader friendly version of the dialog. I also detect if there is a screen reader running, using, and the program starts in the screen reader friendly version if one is detected.

The code to check for a screen reader is quite simple, here it is in Windows C:

BOOL bScreenReaderPresent=0;
SystemParametersInfo(SPI_GETSCREENREADER,0,&bScreenReaderPresent,0);

Bounce Metronome uses Dialogs and Menus extensively

In Bounce Metronome, technically nearly all my windows are what Windows developers call "dialogs" like the Open and Save as dialogs etc.

These are particularly easy to make accessible, so long as you take care of tab order and keyboard shortcuts then that's about all you need to think about.

Menus are similarly accessible "out of the box" if you use the standad Windows menus.

So - if you either build your app using the standard controls, or you build a separate version for Blind users or alternative UI using those controls you are pretty much guaranteed reasonable accessibility.

Then - pay careful attention to tab order. Make sure you have plenty of keyboard shortcuts for the most important controls - that is to say - ones the user is likely to want to use frequently.

That is enough by itself to make most applications very accessible.

Ways of making the standard controls more visually interesting

I achieve nice visuals with the standard controls. by adding textures to these controls by subclassing them or alternatively, by trapping the WM_CTLCOLOR etc. messages, depending on the control. This is technically quite hard to do, and sadly my own code is not yet in a form that is easy to share. To start with I got many visual glitches with this approach but eventually sorted them all out. If anyone wants to know more about how I do it be sure to ask.

However there are interesting articles on CodeProject about other methods of changing the appearance of standard controls that could be worth exploring. This is an example: Perfect Semi transparent Shaped Dialogs with Standard controls (I haven't tested that myself, just looks good from the screen shots and the comments).

Views
Personal tools
Check out the Astonishing Bounce Metronome Pro

Beginners find the bounce wonderfully easy to work with.

Professional musicians are amazed by its advanced rhythm capabilities

Buy Now

box shot for Bounce Metronome

Or, get your free download
Free 30-day trial
Free taster bounce metronome, yours to keep

Or, find out more:
bouncemetronome.com

(By Robert Walker)