C1Label text not accessible via Selenium / Appium

C1Label text not accessible via Selenium / Appium

Posted by: andreas_hron on 5 December 2025, 1:28 pm EST

• 

  andreas_hron

  • Post Options:
  • Link
    Copy

  Posted 5 December 2025, 1:28 pm EST

  I ran into an issue while trying to automate testing of WinForms applications with Selenium / Appium / WinAppDriver.

  C1Label seems not to expose the text or properties through standard Windows UI Automation. This means:

  Inspect.exe cannot see the label text.

  AccessibleName, AccessibleDescription, and AccessibleRole have no effect.

  Selenium / Appium cannot read the text via .Text or GetAttribute(“Name”) like it is possible with the standard label control.

  Is there a solution?

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 8 December 2025, 8:37 am EST

  Hello,

  We created a simple sample and used inspect.exe to check for the Name, ClassName, AccessibleName and AccessibleRole properties and were able to see the correct values. Please see the attached video for the same. ([https://drive.mescius.io/download?file=ExternalShare/WinForms/Videos/behavior_SeleniumAppiumTesting_Winforms.zip])

  Could you please provide the exact steps required to set up the environment and reproduce the incorrect behavior you are observing on your end?

  Regards,
  
  Uttkarsh.

• 

  andreas_hron

  • Post Options:
  • Link
    Copy

  Posted 11 December 2025, 5:28 am EST - Updated 11 December 2025, 5:34 am EST

  Hi Uttkarsh,

  Thank you for the video. It confirms my findings: In the Accessible interface displayed by Inspect, there is no property for reading the text content of the C1 control. To make this clear, I changed the text to “This is the text in the C1Label1” (see attached screenshot). This cannot be found in Inspect.

  It is very easy to reproduce: Place a C1Label on a Winform, set the “TextDetached” property to True so that text can be entered. Then assign any text to the “Text” property and run the project.

  Reading the Text property is essential for our UI tests. Until the problem is solved, we will have to continue using the standard label. Here, the text is accessible via the “Name” attribute.

  Regards,
  
  Andreas

  

  2068×1350 344 KB

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 12 December 2025, 6:52 am EST

  Hello Andreas,

  Thank you for the details. We can observe the behavior.
  
  We have escalated it to the development team for further insights. [Internal Tracking ID: C1WIN-34804]
  
  We’ll get back once we have more information.

  Regards,
  
  Uttkarsh.

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 5 February 2026, 8:59 am EST

  Hello Andreas,

  Thank you for your patience while we investigated this further. As per the development team this behavior is by design.

  C1Label no longer exposes its content through the legacy Microsoft Accessibility (MSAA) framework. Tools such as Inspect.exe rely on this older accessibility architecture, which is no longer supported by our controls.

  C1Label is implemented using the new Microsoft UI Automation (UIA) architecture. In UIA:

  • There is no separate “Text” property available in UIA Tree.
  • The control name is exposed via the UIA Name property, as per Microsoft’s UI Automation guidelines.
  • When TextDetached = True, the visual text is rendered independently and is not surfaced as a distinct automation property.

  When inspected using the officially supported “Accessibility Insights for Windows” tool, the label name is correctly available as part of the UI Automation tree (via the Name property), which is the expected and supported behavior.

  Since there is no UIA Text property available in “Accessibility Insights for Windows” tool, C1 controls do not expose the text in UI Automation tree.

  Accessibility Insights for Windows: https://accessibilityinsights.io/docs/windows/overview/

  Regards,
  
  Uttkarsh.

• 

  andreas_hron

  • Post Options:
  • Link
    Copy

  Posted 5 February 2026, 9:26 am EST

  Hello Uttkarsh,

  Thank you for the investigation.

  While we understand the architectural decision to rely on UI Automation and expose content via the UIA Name property, this behavior is a blocking issue for us.

  Selenium/Appium (via WinAppDriver / UI Automation) represents the current, Microsoft-recommended approach for automated UI testing on Windows. In these frameworks, the Name property is commonly used for element identification and is not a reliable or supported mechanism to validate visible runtime text. When TextDetached = True, the rendered label text is no longer programmatically accessible, making automated verification of UI state impossible.

  Although this behavior may align with UIA guidelines, it does not meet the requirements of modern, enterprise-grade automated testing.

  Without a supported way to access the visible label text via UI Automation (e.g. Value/HelpText or a dedicated text exposure option), C1Label cannot be used in our automated test environment.

  This is currently a blocker for us, and we would strongly appreciate a supported solution or workaround.

  Regards,
  
  Andreas

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 6 February 2026, 4:54 am EST

  Hello Andreas,

  Apologies for the inconvenience.
  
  We have shared your concerns with the development team. Rest assured, we’ll get back once we have more information.

  Regards,
  
  Uttkarsh.

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 10 February 2026, 8:45 am EST

  Hello Andreas,

  We have discussed this further with the development team, and they have decided to output the label text to the Name property in the UIA tree, matching the behavior of the standard Microsoft Label control.

  This change will be included in the 2025v2 hotfix 2 or the 2026v1 release. We will update you as soon as the build is available.

  Regards,
  
  Uttkarsh.

• 

  andreas_hron

  • Post Options:
  • Link
    Copy

  Posted 10 February 2026, 9:19 am EST

  Hello Uttkarsh,

  Thank you for the update. This is great news. We appreciate the team’s decision to align this with the standard Microsoft Label behavior.

  We will wait for your notification regarding the new build.

  Regards,
  
  Andreas

• 

  andreas_hron

  • Post Options:
  • Link
    Copy

  Posted 13 March 2026, 4:25 am EST

  Hello Uttkarsh,

  Thank you again for the update.
  
  Could you please let us know if there is already an estimated date for when the fix will be available?

  Regards,
  
  Andreas

• 

  uttkarsh.matiyal

  

  • Post Options:
  • Link
    Copy

  Posted 16 March 2026, 12:43 am EST

  Hello Andreas,

  The team has created a separate ticket to track this change: C1WIN-35010.

  The requirement has already been implemented internally and is currently under QA. The fix is presently planned for 2025v2 Hotfix 2. If everything proceeds as expected, it should be included in that release, which is scheduled for the end of March.

  However, as mentioned by the team, there is a possibility that the fix may instead be delivered with the 2026v1 release, expected by the end of May.

  Regards,
  
  Uttkarsh.