Tests based on the old implementation of AutomationId could become obsolete

Please describe what inspect and AccessibilityInsights show in cases when we return null for automation ID. This fix changes behavior of ControlAccessibleObject. Previously it was returning a null ID and now it returns Name. I wonder how this is manifested in accessibility tools.

@vladimir-krestov, @dmitrii-drobotov - please review this change

Tests based on the old implementation of AutomationId could become obsolete

Please describe what inspect and AccessibilityInsights show in cases when we return null for automation ID. This fix changes behavior of ControlAccessibleObject. Previously it was returning a null ID and now it returns Name. I wonder how this is manifested in accessibility tools.

@Tanya-Solyanik
A description was being put into PR text description.
"If AutomationId is null then Inspect will display no AutomationId property at all. It shows the property and the value if the field is overridden and is not null (a normal case)."
I'll check this with AccessibilityInsights as well.

• You can also remove UiaCore.UIA.AutomationIdPropertyId => Owner.Name in PrintPreviewControlAccessibleObject and SplitContainerAccessibleObject

These classes introduced after this branch were created (next time I will use cherry-pick to take changes of an old commit to a new branch created from most recent main). I propose we will create a new issue regarding these two classes?

Tests based on the old implementation of AutomationId could become obsolete

Please describe what inspect and AccessibilityInsights show in cases when we return null for automation ID. This fix changes behavior of ControlAccessibleObject. Previously it was returning a null ID and now it returns Name. I wonder how this is manifested in accessibility tools.

@Tanya-Solyanik A description was being put into PR text description. "If AutomationId is null then Inspect will display no AutomationId property at all. It shows the property and the value if the field is overridden and is not null (a normal case)." I'll check this with AccessibilityInsights as well.

I'm interesting, what happens with the rest controls, that have "string.Empty" now for AutomationId?
What AI says?

This commit has been rebased on the most recent main. Conflicts have been resolved.

I checked button control (it has no overridden property and therefore returns null) and AutomationId in both Ispector and AccessibiltyInsights was a number as shown on a screenshot.

Thank you for the experiment. This result matches the pattern that when managed accessible object return null for aq property, UIA reads the value from the default implementation in MSAA proxy.

I checked button control (it has no overridden property and therefore returns null) and AutomationId in both Ispector and AccessibiltyInsights was a number as shown on a screenshot.

Thank you for the experiment. This result matches the pattern that when managed accessible object return null for aq property, UIA reads the value from the default implementation in MSAA proxy.

@Tanya-Solyanik
Should there be any changes in this fix then? Or does only concerns documentation?

Should there be any changes in this fix then? Or does only concerns documentation?

I think this is an acceptable break as long as it is documented.

@Tanya-Solyanik I see you applied "Documentation breaking" label. Could you please elaborate what's breaking here?

@Tanya-Solyanik
CTI testing confirmed our results regarding the pattern that when managed accessible object return null for aq property, UIA reads the value from the default implementation in MSAA proxy.

Could you please elaborate what's breaking here?

We are returning a different value for AutomationID property for some controls. What exactly is different, is not clear as we are getting conflicting results. Specifically the difference between button control with Name=null and ComboBox with Name=null is not clear. I expected that Name=null results in the default MSAA proxy-provided automation ID, but it does not seem to be the case. However AutomationId property is not a required one, and the default MSAA implementation is using control hashes, so this value could vary between app runs, unless explicitly set by the app. Winforms code does not expose this property to be easily overridden directly. More popular control use Control.Name property as AutomationId. As long as we are not breaking cases where devs were setting Name property explicitly and used it as an AutomationID, I think this is an acceptable break.

@dkazennov - CTI test results are not quite what I expected. I'd like to understand why ComboBox.Name=null results in AutomationID as "property not available" instead of a numeric value.

@dkazennov - CTI test results are not quite what I expected. I'd like to understand why ComboBox.Name=null results in AutomationID as "property not available" instead of a numeric value.

I see. I'll try to figure it out than.

Winforms code does not expose this property to be easily overridden directly.

Ah, yes, it vaguely rings true for me. We had to subclass a type and its AccessibleObject to override the accessibility values: gitextensions/gitextensions#9887 (comment)

@Tanya-Solyanik
I have found that in WinformsControlsTests ComboBoxAccessibleObject (inherits ControlAccessibleObject) and ButtonBaseAccessibleObject (inherits ControlAccessibleObject) behave in the same way.

1. If the property private protected override string AutomationId => Owner.Name; is present in ControlAccessibleObject and controls have no Names (commented out this.comboBox2.Name = "comboBox2" in ComboBoxes.Designer.cs) then Insights will show ComboBoxAccessibleObject.AutomationId and ButtonBaseAccessibleObject.AutomationId as 'Property does not exist'.

2. If the property private protected override string AutomationId => Owner.Name; is commented out in ControlAccessibleObject and therefore if private protected virtual string? AutomationId => null in AccessibleObject class plays its role, then Insights will show ComboBoxAccessibleObject.AutomationId and ButtonBaseAccessibleObject.AutomationId as numeric values based on hashcode.

3. If the property private protected override string AutomationId => Owner.Name; is replaced with private protected override string AutomationId => null; in ControlAccessibleObject then Insights will show ComboBoxAccessibleObject.AutomationId and ButtonBaseAccessibleObject.AutomationId as numeric values based on hashcode.

4. If Owner.Name is set to null or string.Empty in ControlAccessibleObject. constructorthen Insights will show ComboBoxAccessibleObject.AutomationId and ButtonBaseAccessibleObject.AutomationId as 'Property does not exist'.

So the exact source of the issue is the new property private protected override string AutomationId in ControlAccessibleObject. If the property returns null, it is being show as a numeric value based of hash.

If the property returns Owner.Name (even if Owner.Name itself is set to null or string.Emtpy), it won't show a numeric value.

2. If the property private protected override string AutomationId => Owner.Name; is commented out in ControlAccessibleObject and therefore if private protected virtual string? AutomationId => null in AccessibleObject class plays its role, then Insights will show ComboBoxAccessibleObject.AutomationId and ButtonBaseAccessibleObject.AutomationId as numeric values based on hashcode.

Do we have tests for this?

2. If the property private protected override string AutomationId => Owner.Name; is commented out in ControlAccessibleObject and therefore if private protected virtual string? AutomationId => null in AccessibleObject class plays its role, then Insights will show ComboBoxAccessibleObject.AutomationId and ButtonBaseAccessibleObject.AutomationId as numeric values based on hashcode.

Do we have tests for this?

I've consulted with @vladimir-krestov and as I understand we can't check with a unit test if MSAA Proxy substitutes null with some native value. I haven't found a way to check for such native value with unit tests.

Conclusion:

If the property AutomationId returns null (but not Owner.Name even if Owner.Name is null or empty) then Accessibility Tools will show AutomationId (e.g. ComboBoxAccessibleObject.AutomationId and ButtonBaseAccessibleObject.AutomationId) as numeric values based on a hashcode.

So on the Windows Forms layer the value is null (in all concluded unit tests Assert.Null(actual AutomationId) would be true ), but on the MSAA Proxy level (between MSAA Proxy and Accessibility Tools) this value is being replaced by a native hashcode.

Rebased on the most recent main branch.
Implemented changes to WebBrowser.WebBrowserAccessibleObject from recent PR #7314