Contents
What is actually happening
macOS exposes a single Accessibility API. Assistive tools use it to read interface content; window managers use it to read and write window geometry. The system does not distinguish between these intentions, and neither does Chromium.
When Chromium detects that an accessibility client is present, it enables its accessibility support, which includes building and maintaining a tree representing page content. On a modest page this is negligible. On a large single-page application with a very big DOM and frequent mutation, maintaining that tree costs real CPU, and it shows up as sluggish scrolling and delayed input.
This has been discussed at length in the project's issue tracker, including by people working on Chrome. The consensus is uncomfortable but clear: a window manager only needs the native window API, but there is no way to request that narrower level, and Chromium has no way to grant it.
Quit the window manager entirely — not just disable shortcuts — and restart Chrome. If the page is still slow, the cause is elsewhere. If it recovers, you have confirmed the mechanism. Note that quitting alone is often insufficient; Chrome may keep accessibility enabled until it is restarted.
Which situations are affected
| Situation | Impact | Notes |
|---|---|---|
| Ordinary browsing, a few tabs | Negligible | Most users never notice anything |
| Large single-page applications | Noticeable | Dashboards, admin consoles, complex web apps |
| Very long documents and huge tables | Noticeable | Thousands of DOM nodes to represent |
| Web-based IDEs and editors | Sometimes significant | Frequent DOM mutation is the expensive pattern |
| Electron applications | Same mechanism | They are Chromium; the effect applies equally |
| Safari and WebKit browsers | Not affected in the same way | Different accessibility implementation |
If you have a machine that feels slow and you are running a heavy web application all day, this is worth ruling in or out. If you browse normally, it almost certainly is not your problem and you should look elsewhere.
The options, honestly stated
There is no setting that fixes this, so what follows is a set of trade-offs rather than a solution.
Use a different browser for the heavy application. Safari and other WebKit browsers do not respond to accessibility clients in the same way. Running one heavy dashboard in Safari while keeping Chrome for everything else is the least disruptive option and costs nothing.
Quit the window manager during heavy sessions. Effective and annoying. Remember that Chrome usually needs restarting afterwards for the effect to clear, which makes this poor for repeated switching.
Reduce the page's weight. Sometimes possible: close idle tabs of the same heavy application, disable extensions that add DOM observers, or use a native client where the vendor offers one. Extensions are worth checking independently — several popular ones cost more than the accessibility tree does.
Accept it. For most people the window management is worth more than the marginal frame rate on one page. That is a legitimate conclusion rather than a resignation.
Toggling the permission off and on: the moment you re-enable it the browser re-enables its subsystem, and with the permission off the window manager does nothing at all. Switching window manager: every one of them requires the same permission and produces the same effect. Chromium command-line flags for forcing accessibility off have been unreliable across versions and are not a recommendation.
Ruling out the other suspects first
Before concluding it is this, eliminate the more common causes of a slow browser, all of which are far more likely:
- Open the browser's own task manager and look at per-tab CPU. One runaway tab explains most cases.
- Disable all extensions, then re-enable them one at a time.
- Check whether hardware acceleration is enabled.
- Check available memory pressure in Activity Monitor — swapping presents as universal sluggishness.
- Test in a fresh browser profile, which separates configuration from the browser itself.
Only when those are clean is the accessibility mechanism worth investigating. Diagnosing it first, because the timing coincided with installing a utility, leads people to remove software that was not the problem.
Get the current build
Rectangle is free and open source. Everything documented here works in the standard build.
Download from rectangleapp.comQuestions
Is this a bug in the window manager?
No. It requests only window geometry; Chromium enables everything because macOS offers no finer-grained permission.
Would another window manager avoid it?
No. All of them require the same permission and trigger the same behaviour.
Does it affect Safari?
Not in the same way. WebKit handles accessibility clients differently.
Does it affect Electron apps?
Yes — they are Chromium. Slack, Discord, VS Code and similar apps are subject to the same mechanism.