MSAA, UIA and WinForms in .Net

Another item for programmers, more on UIA and MSAA and developing accessible user interfaces, following on from using WPF/XAML with MSAA and UIA.

This is a super-quick guide to using WinForms to make UIs that work well with screenreaders like NVDA or Thunder or JAWS.

  • You don’t need to do anything to Button, CheckBox, MenuItem or MenuStrip controls – other than put some text on them! Image-only controls are no good. It’s fine if only the image is shown to the end user and the text is hidden.
  • You can correctly label content controls that don’t have a Text property, like TextBox, ListBox, ListView, ComboBox, ProgressBar and the like, in one of two ways:
    • Put a Label just before the control you want to label in the tab index order. The Text on the Label labels the control. Use the TabIndex property to make sure the order is correct.
    • Set the AccessibleName property on the content control itself. This labels the control for the screenreader.
  • Groupbox controls don’t label their contents, use one of the other techniques here.
  • You almost certainly want to avoid labelling Panel controls, since they are generally for layout, which is communicated to the screenreader user in other ways than labeling.
  • For WebBrowser controls you need to think about the content in terms of web accessibility – use label elements, ARIA, and other HTML accessibility techniques. You might also need to label the actual WebBrowser control on your form with a Label or AccessibleName, just like any other content control.

Unsurprisingly, these techniques are basically the same as writing forms using the Windows C++ API, since WinForms is a wrapper round that.

MSAA, UIA and WPF

A technical note today for programmers.

Screenreaders (blind users) interact with Windows programs through accessibility APIs. The most modern is UI Automation. But the first, and possibly most important still, is MSAA, Microsoft Active Accessibility. Windows will supply information from one interface to the other system if required, so most of the time you shouldn’t have to worry too much.

I’ve been doing some .Net programs using WPF or XAML (that is, not WinForms) and here’s a quick guide to what I’ve found:

  • Buttons and CheckBoxes work fine just as they are. In fact, don’t set any Automation properties or you’ll get odd-looking controls in MSAA.
  • ListBox, ComboBox, TextBox, ProgressBar work fine for their contents just as they are. But:
  • Labels don’t label Listbox/ComboBox/TextBox/ProgressBar unless you use LabeledBy.

In C++ applications you associate labels (e.g. “Enter username:”) with the control they are labelling (e.g. a textbox for the username) by using tab order. The label with tab index N labels the control with tab index N+1. So label with tab index 0 provides the name to the combobox with tab index 1.

In WPF you have to set this explicitly using AutomationProperties.LabeledBy, like this:

<Label Content="A ListBox Control:" x:Name="lblList"></Label>
<ListBox AutomationProperties.LabeledBy="{Binding ElementName=lblList}">
  <TextBlock>Elephant</TextBlock>
  <TextBlock>Koala</TextBlock>
</ListBox>


Note the funky “Binding” code – you can’t just use the x:Name of the label. Notice also that your Label must have an x:Name! You can also use a TextBlock instead of a label. Generally the pattern is:

<TextThing Content=”The label for the other control” x:Name=”textThingLabel” />
<OtherControl AutomationProperties.LabeledBy=”{Binding ElementName=textThingLabel}” />


Anyway, that suffices for the basics of MSAA/UIA support for WPF if you’re writing .Net Windows applications.