How to Code WPF Applications for Accessibility

Guidance and code examples to help you make your Windows Presentation Foundation apps fully accessible

In this article, I want to walk you through the process of making a Windows Presentation Foundation (WPF) application fully accessible to users with disabilities. I intend to do so by example; that is, I'll focus on the actual steps and the associated code snippets first and foremost. That way, you can always refer back to this article when you develop WPF-accessible applications. The prescriptive guidance that follows will focus on using Microsoft User Interface Automation (UIA) as a tool to meeting accessibility mandates.

I'll assume that you've had the required accessibility 101 class and that you are up to speed on the terminology. If you haven't, it's a good time now to do some reading before continuing. See, for example, my article "Assess Your Access." So where do you begin?

Start with your user interface (UI) controls. If your application does not expose a UI, you don't need to be concerned with accessibility. If your application has a UI, then you need to focus on accessibility. For that, you'll need to make sure that any controls that make up your UI components are accessible. I'll explain how to do this by walking you through a set of design scenarios; that way, you can pick whatever design scenario applies to you.

WPF Design Scenarios
Here are the four WPF design scenarios I'll discuss:
• Scenario 1: WPF application with native controls
• Scenario 2: WPF application with custom controls where the custom controls are based on native controls
• Scenario 3: WPF application with custom controls where the custom controls are not based on native controls
• Scenario 4: WPF application with legacy controls

Note that the term native control refers to the set of controls that ship with WPF and are supported by Microsoft. For instance, a WPF Button or a WPF Label control is considered a native control because it ships with the framework and is supported by Microsoft. The term legacy control refers to the set of non-WPF controls that may be embedded in a WindowsHost control in a WPF application.

Also note that the scenarios using native controls are based on Microsoft UI Automation. Per MSDN, "Microsoft UI Automation is the new accessibility model for Microsoft Windows and is intended to address the needs of assistive technology products and automated testing tools". This is the main reason why I used UI Automation as an accessibility implementation tool. If your controls follow the UI Automation specification, your controls and your application will be accessible.

Let's create a test project that we can use to work with these scenarios. Create a WPF application based on a WPF Application template, as Figure 1 shows.


Figure 1: Creating a test project for WPF accessibility scenarios
Figure 1: Creating a test project for WPF accessibility scenarios


Accept the default name. In the design view, add a button to the form by dragging a WPF button control to the form or entering the XAML fragment in the XAML file, as Figure 2 shows.

Figure 2: XAML button fragment


Let's pretend this simple application is our world-class application. It won't win any awards, but you will come to appreciate why I've kept it simple.

Solution to WPF Design Scenario 1
To work with the first WPF accessibility design scenario, you'll need to start by setting accessibility properties. Here are the steps to do so:

1. Identify the control on the form. It is a native WPF button control.
2. Go to this link: This link opens to a page that contains information about support for control types in UIA. Each link on that page shows the control specification for all the supported native controls in WPF.
3. Review the control specification for the type of control on the form. In this case, it is a button control, so click the second link, UI Automation Support for the Button Control Type. (The equivalent link is here:
4. On the Button Control Type page, review and implement each section for the button control that is missing. Determine the set of properties that need to be implemented by comparing the button control's available properties in the example against the properties in the Required UI Automation Properties table. Notice that there are 12 properties for the button control. That doesn't mean that I have to implement all 12; most are implemented for me because the button is a native control. The properties that are not implemented are typically those where Visual Studio has no way to guess your intention.

Figure 3 shows that the simple test application contains three empty fields. Two of these fields (AcceleratorKeyProperty and HelpText) are required fields as per step 3.

I'll show you how to fill in one of these required properties. You can then use it as a pattern to tackle the remaining 10 properties for the button control on the form if you need to provide meaningful values for these fields. Figure 4 shows one property copied here for your benefit.


Figure 4: Accessibility property for the button control
Figure 4: Accessibility property for the button control

According to Figure 4, AcceleratorKeyProperty property is required. The AcceleratorKeyProperty refers to a shortcut key that can be used to invoke the control's pattern. For this example, I'll choose to add the letter B as my accelerator. When the user presses Alt+B, the button click event will fire.

To set this accelerator, open the XAML page and find the button control. Enter the following in the XAML button fragment:

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.