GWKB2032 : General Software Accessibility Guidelines

Product: Window-Eyes
Author: Aaron Smith
Date Added: 08/16/2013
Last Modified: 09/18/2013

Understanding Accessibility

Before you can begin to make an application accessible, it helps to­ know what "accessible" means. The Microsoft Accessibility website contains a host of information for discovering how people with all types of disabilities interact with their operating system and applications. With our development of Window-Eyes, we at GW Micro are primarily focused on visual disabilities, and strongly recommend reading through the Resource Guide for Individuals with Visual Difficulties and Impairments to gain an understanding of how an individual with a visual impairment may be accessing your application. Building With the Right Tools

Once you have an understanding of how someone with a disability may be using your application, it's time to pick the right tool for the job in terms of creating an accessible software package. Microsoft tools, such as Visual Studio, are going to provide you with out-of-the-box components based on sound programming standards. In other words, controls such as edit boxes, buttons, combo boxes, radio buttons, check boxes, menus, tab controls, progress bars, scroll bars, and so on are already accessible (with little to no work, depending on the control) when using Visual Studio. Visual Basic is another Microsoft development tool that can create accessible applications without much work. Some other non-Microsoft development tools that can be used include Borland C++ and Delphi.

Regardless of which development platform you use, there are a few important points to keep in mind:

  • Use controls that are provided by the operating system to ensure maximum accessibility.
  • If you must use a custom control, investigate methods for providing information to an accessibility tool such as Window-Eyes (see MSAA below).
  • Provide textual information wherever possible. In other words, make sure each control has been labeled so there's no confusion about that control's purpose.
  • Ensure total keyboard access. Blind computer users have little use for the physical mouse. Make sure that each corner of your application is accessible via keystroke.
  • Logical Tab order
  • Don't trap focus

Ensuring Accessibility

Microsoft has developed a technology that allows you to implement accessibility into applications, essentially guaranteeing accessibility. This technology is called MSAA (Microsoft Active Accessibility). The following is taken from the Microsoft Active Accessibility page:

Microsoft Active Accessibility 2.0 is a COM-based technology that improves the way accessibility aids work with applications running on Microsoft Windows. It provides dynamic-link libraries that are incorporated into the operating system as well as a COM interface and application programming elements that provide reliable methods for exposing information about user interface elements. For a copy of the Active Accessibility SDK documentation formatted in Microsoft Word or WinHelp, refer to

If you invest the time to implement MSAA support in your application, make liberal use of the MSAA testing tools, like AccEvent, to ensure correct implementation. The MSDN MSAA reference provides a welth of information.

Despite the robust features of MSAA, you may find supporting Win32 messages a more viable option.

If you subclass or derive your own custom control from a Win32 control, and you allow the default message handler to handle messages (or pass messages that you don't specifically care about to the default handler) then your control should be accessible with no extra work.

If you create a custom control that functions like a Win32 control, but is not derived (or subclassed) from a standard Windows control, then you will need to handle the Win32 messages that Window-Eyes sends to that control. You can contact our support team at 802-362-3612 (or via email at for additional information regarding Window-Eyes messages.

Working With Window-Eyes

You may encounter a situation where you need to know if an accessibility aid, like Window-Eyes, is running, and if so, provide alternative content. For example, you may choose to provide a skinned window to people who are not running an accessibility tool, or a non-skinned window for people who are.

  • A general way to determine if any accessibility aid (any that supports this feature, that is) is running is to check to see if the Screen Reader flag has been set, using the SystemParametersInfo() function with the SPI_GETSCREENREADER parameter.
  • If you need to know specifically that Window-Eyes is running, you can search for the Window-Eyes class name GWMExternalControl, and window title External Control. For example:
// check to see if Window-Eyes is running
 if (FindWindow("GWMExternalControl", "External Control")) {
     windoweyesLoaded = TRUE;
 } // end if
 else {
     windoweyesLoaded = FALSE;
 } // end if 
  • You may also choose to communicate directly with Window-Eyes using the Window-Eyes API via COM. There are only two methods: SpeakString, and Silence.

Using a VBA macro, you might do the following:

Sub SaySomething()
    Set myobject = CreateObject("GWSpeak.Speak")
    myobject.SpeakString("This is the text you want to speak")
 End Sub

The Silence method makes Window-Eyes stop speaking what was currently being spoken and flushes any queued text to be spoken. It does NOT stop future text that will be queued by Window-Eyes or any future calls to SpeakString. It takes no arguments, so you would simply call it by saying:


If you're using C++ (using Microsoft Visual Studio 6 or greater), you can download the "sayit" project. SAYIT.EXE is a very simple command prompt example which allows you to specify a string to speak (specified in quotes). If no string is specified, SAYIT will call the Silence method causing Window-Eyes to silence all pending speech. Some examples are:

C:\SAYIT "this is a test string which will be spoken"
 C:\SAYIT testing

When you are using SAYIT, remember that, at the command prompt, Window-Eyes will silence speech with each keypress (by default). If you're using C#, you can download the sample C# GWSpeak project, graciously donated by Peter Laursen of

For other languages, or for reference, download the Window-Eyes API IDL source file.

  • Starting with Window-Eyes 7.0, you can take advantage of powerful, industry standard scripting support, which takes the previously mentioned COM interface to great new levels. For more information, visit the App Central Developer Resources page.

Testing Accessibility

Aside from implementing MSAA, there are two other methods of ensuring total application accessibility:

  1. Unplug your physical mouse.
  2. Turn off your monitor.

Although you may scoff at the idea of removing the two most common tools used for creating your application, imagine how a blind individual uses a computer. To a blind individual, no monitor or mouse is hardly a stumbling block. You should have the same confidence in your ability to navigate your own application without being able to see what's happening on the screen if you expect the same of your customers.

Use Your Users

The best way to know whether or not you have created an application that is accessible is to have someone using an accessibility aid (such as Window-Eyes) test your application. The most popular way to find someone to test your application is to subscribe to the Window-Eyes Talk email list. Almost all of the members of this list have a visual impairment of some sort, and are familiar with Window-Eyes (and usually other adaptive products too). They will be able to provide you with the necessary feedback regarding the accessibility of your application.

Additional Resources