In Chrome and Edge v117 the Active Accessibility support is broken for IFRAMEs and PDFs

Starting with Chrome and Edge v117 we are seeing a new bug that affects Active Accessibility support for web pages that contain IFRAMEs or PDF documents.
This bug means that <ctrl /> selectors for those web pages might fail.

Available workaround

If you are affected by this issue, the immediately available workaround is to start the browser with this flag added to the command line:
--force-renderer-accessibility=complete

Since UiPath.UIAutomation.Activities v23.8.0-preview this can be easily done from Project Settings:
Project Settings → UI Automation Classic → Browser → Extra arguments for OpenBrowser Chrome/Edge

Notes:

Code fix

A code fix for this issue will be included in UiPath.UIAutomation.Activities v23.10.0-preview, which is scheduled to be released next week.
This fix will remove the need to add the --force-renderer-accessibility=complete flag when starting the browser.
However, if you are affected by this issue we strongly recommend keeping this flag to avoid issues such as this in the future.

Why is the --force-renderer-accessibility=complete flag not added by default?

Enabling the support for Active Accessibility in the browser causes a slightly higher memory consumption.
To avoid this overhead the UiPath.UIAutomation.Activities enables support for Active Accessibility only when needed - e.g. when searching for browser UI elements using <ctrl /> selectors.
However, adding the --force-renderer-accessibility=complete flag force-enables support Active Accessibility, and it will help guard against issues such as this in Chrome/Edge v117 and this in Chrome/Edge v114.

Further info regarding this bug

This bug was caused by this Chromium change:
[A11y] Fix for longstanding hypertext errors
We are going to report this issue as a Chromium bug, but from our past experience we expect that it will be a while until this bug is fixed in Chromium.

Below is an example of a selector that is affected by this bug.

<wnd app='chrome.exe' cls='Chrome_WidgetWin_1' title='HTML Iframes - Google Chrome' />
<ctrl name='HTML Iframes' role='document' />
<ctrl name='W3Schools HTML Tutorial' role='document' />
<ctrl name='HTML Tutorial' role='document' />
<ctrl name='JAVASCRIPT' role='link' />

Repro steps:

  1. Make sure that Chrome v117 is completely closed
  2. Open Chrome and navigate to https://www.w3schools.com/html/html_iframe.asp
  3. Validate the selector from above using UiExplorer
  4. Observe that it fails to match the target element → this is the bug
  5. Refresh the web page
  6. Validate the selector from above using UiExplorer again
  7. Observe that it now matches the target element.
6 Likes

Hello

Thank you for this very useful information.

Is this a bug for Chrome or a deliberate development? Would you have the bug reference for chrome in this case? We’re interested in this since we’re only deploying peer versions of Edge, and in this case, this problem is likely to appear around 12/10/2023 with Edge 118.

Sincerely

Hello @jean-michel.varvou,

This is a Chromium bug that appeared as a side effect of this change:
[A11y] Fix for longstanding hypertext errors

Hello everyone,

The code fix for this issue is now available in the following versions of UiPath.UIAutomation.Activities:

These patches also add the option to pass extra command-line arguments to the browser opened using the Open Browser / Use Browser activities.
This can be done by setting the appropriate environment variable:

  • UIPATH_EXTRA_CMD_ARGS_CHROME
  • UIPATH_EXTRA_CMD_ARGS_EDGE
  • UIPATH_EXTRA_CMD_ARGS_FIREFOX

This can be used to force-enable the Active Accessibility support in Chrome and Edge to avoid issues like the broken Chrome/Edge Active Accessibility support from versions 114 and 117.
For Chrome, this can be done by setting environment variable UIPATH_EXTRA_CMD_ARGS_ CHROME with the value --force-renderer-accessibility=complete.
For Edge, this can be done by setting environment variable UIPATH_EXTRA_CMD_ARGS_ EDGE with the value --force-renderer-accessibility=complete.
These environment variables can be set using the Set Environment Variable activity.

Hi @Luiza_Surdu-Bob ,

I hope this message finds you well. I’ve encountered the same issue, but I’m having some trouble grasping the process of implementing the suggested solution, which involves starting the browser with the following command line flag: --force-renderer-accessibility=complete.

I would greatly appreciate it if you could provide a bit more detail or a step-by-step guide on how to apply this flag to resolve the issue. Your guidance will be incredibly valuable to me.

Thank you in advance for your assistance!

Hi @vanzuylen.lard ,

You can start the browser with the Active Accessibility support enabled by adding the flag as command line argument in the Use Application/Browser activity in the Input → Unified Application Target → Arguments section:

You can check if the browser was opened with accessibility options enabled from chrome://accessibility:

With UiPath.UIAutomation.Activities v23.10.3 (released on 23 October 2023) this can also be done from Project Settings → UI Automation Classic → Browser → Extra arguments for OpenBrowser Chrome/Edge (see the image from the initial post). This will apply to all open browser activities in that project.

In addition, as mentioned in the previous message, a code fix for this issue is now available starting with the following versions of UiPath.UIAutomation.Activities package:

  • 23.10.3
  • 23.4.9
  • 22.10.9
  • 22.4.11
  • 21.10.10
  • 20.10.15

Let me know if this clarifies your question.

Best regards,
Luiza

1 Like