Why AutomationProperties are needed in WPF

Question

As per my understanding, AutomationProperties can be utilized to identify names of controls by UI Automation clients.

I want to understand need to create separate set of automation properties, and not using x:Name for the same purpose.

Answer 1

Let’s think about a text box, in your application it is the PhoneNumberTextBox, and you also have a PhoneNumberLabel, and PhoneNumberValidationTick. These are then displayed inside of a group box with a label showing “Customer”

A blind person trying to use your application would like the screen reader to say “Customer Phone Number” when they tab into the text box, likewise a tester writing an automated UI test for your application would like to be able to find the text box that contains the “Customer Phone Number”.

Now what if your application has been translated to German…. Would the blind user not want the screen reader to say ”Kundentelefonnummer“?

Now imagine you change your app to use a PhoneNumberInputControl, you will likely want to change the names of the control in your code, but the tester would rather wish that the control name does not change….

So we need the concept of a name that is used by programs that try to walk the “important” logical controls of an application at run time and automate something about how a user interacts with the application.

Answer 2

I consider my answer came a little bit late, but I found a proper explanation and I would like to share it with all programmers to improve their work in this field of automation.

Nowadays, I'm mostly working with some automation tools called RPAs, specifically UiPath and Automation Anywhere.

For many months I have been struggling with some tools to be automated because they were developed in WPF and not Windows Forms, which make them very hard to automate and we have depended a lot in image recognitions not because they were poorly designed or didn't work as expected, but because the AutomationProperties were never considered in any project.

In order to find the answer why the controls were not recognized by any RPA and we were forced to use Image Recognition all the time, especially in tools like UiPath that is being built in VB.NET, which should have full connection with Windows, it was incredible to believe that it couldn't work well and it pushed me to investigate deeper about the root cause and I created the following test case.

A basic WPF application without any automation properties (as default) that contains just a Grid, a Label, a Button and a TextBox:

<Window x:Class="UiPathExample.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:local="clr-namespace:UiPathExample"
    mc:Ignorable="d"
    Title="MainWindow" Height="350" Width="525">
    <Grid>
        <Button x:Name="button" Content="Button" HorizontalAlignment="Left" Margin="91,60,0,0" VerticalAlignment="Top" Width="75"/>
        <Label x:Name="label" Content="Label" HorizontalAlignment="Left" Margin="82,121,0,0" VerticalAlignment="Top"/>
        <TextBox x:Name="textBox" HorizontalAlignment="Left" Height="23" Margin="300,135,0,0" TextWrapping="Wrap" Text="TextBox" VerticalAlignment="Top" Width="120"/>
    </Grid>
</Window>

Now, if you try to search for any control with Spy++, Ui Explorer from UiPath, Object Cloning from Automation Anywhere, etc. This is your result:

All controls are undiscoverable by any RPA or tool. For this example, I'm using the Ui Explorer of UiPath (I could have used Spy++ too and I would have got the same result); however, if you modify the code a little bit and add all Automation IDs as suggested in this site:

http://www.jonathanantoine.com/2011/11/03/coded-ui-tests-automationid-or-how-to-find-the-chose-one-control/

The new code will look like this:

<Window x:Class="UiPathExample.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:UiPathExample"
        mc:Ignorable="d"
        AutomationProperties.AutomationId="Window1"
        Title="MainWindow" Height="350" Width="525">
    <Grid AutomationProperties.AutomationId="Grid1">
        <Button x:Name="button" Content="Button" HorizontalAlignment="Left" Margin="91,60,0,0" AutomationProperties.AutomationId="btnButton1" VerticalAlignment="Top" Width="75"/>
        <Label x:Name="label" Content="Label" AutomationProperties.AutomationId="lbl1" HorizontalAlignment="Left" Margin="82,121,0,0" VerticalAlignment="Top"/>
        <TextBox x:Name="textBox" HorizontalAlignment="Left" Height="23" Margin="300,135,0,0" TextWrapping="Wrap" Text="TextBox" VerticalAlignment="Top" Width="120" AutomationProperties.AutomationId="txtAutomationEx"/>
    </Grid>
</Window>

And now all controls become accessible to the Ui Explorer like the button that I highlighted:

Based on my personal experience this is why I consider we should use them; especially, in these times when RPAs are becoming iconic in any industry. Also, you are going to save a considerable amount of time for you or your team if anyone will automate the tools you are building in the future because without those properties the automation would be highly inefficient since you will rely on image recognitions all the time as it was in my case.

Furthermore, here you can read more about the Automation Properties: https://learn.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-properties-overview

Happy Automation!

P.S.:

An interesting fact in my investigation is that any Windows Forms project has its controls already exposed since the beginning to any automation tool without additional effort and that's why they are faster to automate.