Custom Controls

You should generally avoid using nonstandard custom controls, because they are not fully usable with screen review or voice recognition utilities. Custom controls present a number of problems, because accessibility aids cannot identify the type of the control or its state. In addition, if the control does not have its own window, accessibility aids are not able to watch it receiving and losing focus.

At this time, there is no standard way for applications using nonstandard controls to work well with accessibility aids. However, you can use these techniques as short-term solutions:

If the custom control has its own window, you can return a descriptive string when the control is queried using the WM_GETTEXT message. For example, a control that appears as a button with the label Print could return the string "Print button" to convey both the control type and the label. The same string would be appropriate if the control looked like a button, but had a graphic showing a printer rather than a textual label. Likewise, a custom control that behaves like a check box could return a caption string "Printing Enabled check box, checked."
If the custom control has no window, you can associate a descriptive string with the control by using the techniques described in "Use of Bitmapped Text" later in this document. This string can follow the same conventions described in the previous paragraph.
If the custom control has no window, you can convey the focus location to accessibility aids by moving the system caret as described previously in "Visual Focus."
When using custom controls that have their own window, you should support the WM_GETDLGCODE message, which identifies the keyboard input that is supported and also the equivalent standard control if there is one. The one form of custom control that is regarded as accessible is OLE controls. For more information, see the following section.