Microsoft is testing a major change to how Chromium handles accessibility on macOS, and the early results look interesting, especially for memory usage.
First spotted by Techdows.com, in a Microsoft-authored Chromium commit marked “DO NOT SUBMIT,” the company describes a rough prototype for a dedicated out-of-process accessibility system on macOS.
Microsoft wants VoiceOver and other accessibility features to work across both the browser interface and web content without forcing the browser process to own the full web accessibility tree.
However, Microsoft clarified that the feature is in prototype state and is not shipping today. The change is described as a Strategy 1 validation, which means it is mainly a proof of concept to confirm that the architecture can work end-to-end.
Right now, Chromium’s macOS accessibility path is largely browser-hosted. That means the browser process plays a big role in owning and exposing the accessibility tree for web content. Microsoft’s prototype changes that by adding a new AccessibilityMacRendererHosted feature path.
With this new path, legacy browser-hosted accessibility remains available, but eligible macOS web content sends serialized accessibility updates to a utility process called MacAccessibilityProvider. This separate process then owns the web BrowserAccessibilityManager and gives the browser an NSAccessibilityRemoteUIElement token, which is presented under RenderWidgetHostViewMac.
That sounds very technical, but the basic idea is simple that the browser no longer needs to directly own the web accessibility tree. A separate process handles it, and macOS still sees an accessibility element that VoiceOver can interact with.
Microsoft says the prototype already validates the most important part: VoiceOver activation reaches web content end-to-end through the hosted path. In its local testing, focus, press, text input, and Space key actions all reached the web DOM state in both the legacy and hosted paths.
The company also used a VoiceOver verifier where VO_BUTTON_SENTINEL_35337 successfully changed to VO_BUTTON_PRESSED_35337 through the new hosted accessibility route. That confirms VoiceOver was not just seeing the element, but also activating it through the new path.
The memory numbers are the most interesting part.
Microsoft tested the prototype against the HTML spec, which is a heavy page and a good stress test for browser internals. In the local release ARM64 build, the browser footprint reportedly dropped from 1837.7 MiB to 270.5 MiB. Renderer memory stayed almost the same, moving from 1698.8 MiB to 1694.3 MiB.
That is a massive reduction in the browser process footprint, at least in this specific test. It suggests that moving the accessibility tree out of the browser process could make a real difference on large pages, especially when accessibility support is active.
But there is an important catch. Microsoft says the provider still unserializes a full accessibility tree. So this prototype does not remove the duplicate tree yet. It mostly proves that the browser process can stop owning the web accessibility tree while VoiceOver still works properly.
The next step, referred to as Strategy 2 in the commit, would be more ambitious. That work would try to remove the duplicate tree and cut down most of the serialization overhead. In other words, Microsoft has proven the routing model can work, but the real optimization work is still ahead.
For users, this does not mean Edge or Chrome on macOS will suddenly use less memory tomorrow. The commit is clearly marked as a prototype and not ready for submission. But it does show Microsoft is looking at deeper Chromium architecture changes to improve accessibility and reduce browser memory pressure.
If this work eventually lands in Chromium, it could benefit Chromium-based browsers on macOS, including Microsoft Edge and Google Chrome. For now, it is an early experiment, but it points to a cleaner design where macOS accessibility can work end-to-end without keeping so much responsibility inside the main browser process.