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}">

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.

Leave a Reply

Your email address will not be published. Required fields are marked *