Google Chrome accessible tree cache issue with UI Automation

Question

Google Chrome does not refresh accessibility elements (AutomationElement) when a user scrolls down in the browser.

To reproduce it:

1. Enable renderer accessibility with : "chrome --force-render-accessibility" or by setting on Global Accessibility at "chrome://accessibility".
2. Go to http://en.wikipedia.org/wiki/Google
3. Open inspect.exe in UI Automation Mode (from Windows Kits), look for "Links to related articles" element.
4. Come back to Chrome, Scroll down until "Links to related articles" at the bottom is visible
5. "Links to related articles" element is marked off screen

---

I found some manual solutions that can force Chrome to refresh it:

1. Set Zoom to 90% then set it back to 100 % (very very ugly way)
2. Switch accessibility off then switch on in chrome://accessibility/

What I'm looking for is the ability to do one of these operations programatically, or any operation that can make Chrome refresh its cache tree.

---

What I've tried:

• Resize window with PInvoke/MoveWindow
• Redraw Window with PInvoke/Redrawwindow
• Build a chrome extension and force zoom to 100% on demand: chrome.tabs.setZoom(null, 0); (working but blink and slow down the window)

None of these are working properly.

EDIT: Tested with Google Chrome 40.XX, 41.XX, 42.XX, 43.XX, 44.XX, 45.XX, 46.XX, 47.XX.Dev, 48.XX.Dev under Windows 7.

Picaresque

You should report this to chromium's accessibility bug on Windows: code.google.com/p/chromium/issues/… – Ozonide

Can you share some information on what you're trying to do once you solve the issue? maybe there's a workaround... – Participation

@Ksv3n please post the link to bug that you posted – Pontifex

@Ksv3n Have you tried doing the same test on some other browser? Firefox may be? – Discuss

@Emzor thanks for trying to make edits, but please refrain from making trivial edits to make links look "better". Sometimes links are better shown in the full so user can copy and paste it if needed. – Rifling

Answer 1

Scrolling in simple pages is optimized to not require computation from the renderer. Only the compositor and the GPU are needed to scroll therefore the render tree which is only updated from the renderer is still the same.

Requiring the renderer to traverse the DOM and update the Accessibility tree during a scroll runs contrary with the several years effort of having smooth scrolling, specially for touch devices so I don't think you are going to get traction on a bug fix.

Your idea of an extension I think is the best (although ugly) compromise. But rather that changing zoom, doing a small mutation of the page (or DOM) might be a better solution. Try for example adding a invisible (or nearly so) element with a low z-order. You will also need to rate control the mutation so it only happens 1 times per second or even less often.

Louanne

Breaking accessibility when it is explicitly asked in configuration or parameters, in the name of smother scrolling seems bad. – Milker

@Milker that is why extensions exist. When your priorities run contrary to the browser priorities you can take over. Your customer installing the extension signal they agree with you and not with Chrome team. – Louanne

Answer 2

Chrome's multi-process architecture is different from that of any other browser. For security, the main browser UI is in one process, and web pages are run in separate renderer processes (typically one per tab). The Renderer processes are the only ones with a representation of the webpage's DOM and therefore all of the accessibility information, but the renderer processes are specifically not allowed to interact with the operating system (sending or receiving events or messages) - in particular, the renderer processes cannot send or receive accessibility events.

Lehmann