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.
3 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