Browse DevX
Sign up for e-mail newsletters from DevX


How to Build Accessible Windows Forms Applications with .NET : Page 2

Open your favorite .NET application, then close your eyes and try using the program. Tough, isn't it? But that's what using your applications may be like for disabled computer users. As a responsible developer, you can solve this problem by using these techniques to add Active Accessibility features to your application.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

What Are Accessibility Aids?
In general, accessibility aids are specialized programs and devices, such as the Braille bar (see the Related Resources links for more information) that help people with disabilities use computers more effectively. Aids fall roughly into the following categories:
  • Screen enlargers for people who have low vision
  • Screen readers for people who are blind
  • Voice input utilities for people who are not able to use mouse or keyboard for input
  • Alternative input devices
  • On-screen keyboards and keyboard enhancements for people that have problems using a keyboard, for example, the inability to hold down two or more keys at the same time)
Active Accessibility increases the options for people who depend on accessibility aids to use computers. Microsoft is not the only company developing aids; there are also many third party aids available. Visit the Microsoft Overview of Assistive Technology for a catalogue of certified aids.

How Does Active Accessibility Help Developers?
Active Accessibility provides dynamic link libraries that are incorporated into the operating system and offer standardized COM interfaces, API elements, and .NET Framework classes that cooperate with your applications and help replace the unreliable and less portable techniques used in the past, such as analyzing screenshots. Most system-provided user interface elements, such as list boxes, drop down lists, buttons, check boxes, and buttons are designed to expose this information by simply setting the accessibility properties. Notifications about events such as screen changes, enabling or disabling a control, and setting a default action are also fully supported by the Active Accessibility framework. Active Accessibility Architecture
Applications that use only standard user interface elements typically get full Active Accessibility support without much additional development work on your part. However, some important exceptions to this rule are controls that:

  • Have been subclassed
  • Do not have the HASSTRINGS style set
  • Are owner-drawn
For these, you must provide custom accessibility code. Here's a brief overview over the architecture of Active Accessibility, so that you can follow the sample source more easily. About Servers and Clients
The dynamic link library OLEACC provides the Active Accessibility runtime and manages requests from clients for information about servers.

For this article, a client is any program that uses accessibility to access, identify, or manipulate the user interface. Thus the term client can include accessibility aids, automated testing tools, computer-based training applications—briefly, any application that consumes information exposed through active accessibility interfaces. A server can be any control, module, or application that uses Active Accessibility to expose information about its user interface. Servers and clients communicate with one another by sending event notifications (for example by calling NotifyWinEvent) and responding to client requests for access to user interface elements (for example by handling WM_GETOBJECT messages). Clients register to receive notifications through a mechanism called Window Events, or WinEvents. Because the .NET Framework wraps WinEvents neatly, you don't have to touch it when writing servers. You should take a look at WinEvents in the MSDN Library if you are interested in the details, but broadly, the rationale is that clients need to know when the server's user interface changes so they can convey that information to the user.

Active Accessibility Objects
In accessible applications two types of UI elements provide accessibility information: accessible objects and simple elements. Although most applications contain both, accessible objects are more common than simple elements. To be an accessible object, a UI element must implement the IAccessible interface, whereas a simple element shares an IAccessible object with other elements and relies on that IAccessible object to expose its properties. A simple element requires not only an IAccessible object, but also a child ID; the IAccessible object shared among simple elements often corresponds to a common parent object in the user interface. For example, system dropdown lists expose an accessible object for the overall drop down list box and simple elements for each list item. In this case the IAccessible object for the drop down list is called the parent or container of the simple elements corresponding to the list items.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date