Glad you've figured out an answer yourself; here's some more context to answer the "why" in comments.
I've got this error in a setup like so. Using 2 laptops (one with Kubuntu for work, another I personally own, with Arch) — I've got somewhat lazy, and instead of physically picking up the other laptop, used X11 Forwarding a.k.a. ssh -X.
Detour: X11
Conceptually, X11-forwarding is a "remote desktop" technology, like VNC, RDP... but with a twist. It doesn't do a video-stream of the remote desktop; instead, it rides the networked architecture of X11 protocol.
Back in the days of X11 conception (1980-s!), all screens and keyboards were "remote": one huge mainframe cabinet was running the OS processes backing GUI apps of many users (typically all computing users in an organization owning that mainframe computer). As a consequence, in X11 pixel drawing parts are done client-side.
VNC-style remote desktop X11 forwarding
──────────────────────── ──────────────
┌─────[Client machine]──────┐ ┌──────[Client machine]────────────────────────────────┐
│ │ │ │
│ Runs VNC viewer app │◄──┐ │ - Runs X server │
│ │ │ │ - Runs local GUI apps, i.e. those using DISPLAY=:0 │
│ • remote GUI embedded in │ │ │ - Renders remote GUI apps which X11-connect to it, │
│ VNC viewer window │ │ │ to network address like client.local.lan:0 │
│ │ │ │ Usually nowadays, ssh -X secures the X11 traffic │
└───────────────────────────┘ │ │ by tunnelling it; so e.g. DISPLAY=localhost:10.0 │
│ │ This localhost is interpreted by app running on │
network│ │ the server machine! │
│ │ Because SSH tunnel. ┌─────┐ ┌─────┐ │
┌─────[Server machine]──────┐ │ │ ┌──────►│ GUI │ … │ GUI │ │
│ │ │ ├───────────────────┐◄──────┘ └─────┘ └─────┘ │
│ Runs VNC server app │◄──┘ ┌─►│ SSH tunnel egress │ local X11 server │
│ │ │ └───────────────────┴──────────────────────────────────┘
│ • streams pixels of the │ │
│ entire screen │ │ ┌──────[Server machine]────────────────────────────────┐
│ • receives client input, │ │ │ │
│ forwards it to GUIs │ │ │ - May lack any screens, input devices, GPUs │
│ │ │ │ - May not run any X server │
│ ┌─────────┐ ┌─────────┐ │ │ │ - Yet, runs remote GUI apps, as OS processes │
│ │ GUI app │ … │ GUI app │ │ │ │ - GUI stuff lives on client machine's X server │
│ └─────────┘ └─────────┘ │ │ │ - Painting commands and input events │
│ │ │ │ travel within the X11 connection. │
└───────────────────────────┘ │ │ │
│ │ ┌─────┐ ┌─────┐ │
│ │ ┌──────►│ app │ … │ app │ │
│ ├────────────────────┐◄─────┘ └─────┘ └─────┘ │
└─►│ SSH tunnel ingress │ OS processes │
└────────────────────┴─────────────────────────────────┘
In the common use-case of personal computer, the X-server and client-GUIs run on the same machine, so this funny X11 protocol runs over localhost mostly invisibly.
But it also works over real network, and surprisingly well! Especially if supplemented with ssh's built-in compression, -C. For example, I can run Brave (a Chromium-based web browser) "remotely" with ssh -CX pasocon.local brave, and it's pretty much usable over WiFi.
Detour: accessibility on Linux desktop
Won't say much, not an expert here, barely familiar at all. But I'll say 2 things.
First, observe how much more amenable to assistive technologies X11 forwarding architecture is, in principle. E.g. screen-reading a raw video-stream of remote desktop, (though AI tech may fix that some day), is significantly more challenging than screen-reading an X server state or event/command stream. Via X11 protocol, apps will say hey X server, paint a text "Lorem ipsum" in this font at these coordinates; change this button's color; collapse this menu, etc.
Second, notice how most of shenanigans around handling input to embedded desktop in VNC/RDP style (focus-grabbing, escapes for special key combos a-la Ctrl-Alt-Del, correctly remapping keyboard layout, the clipboard, etc etc) simply go away in X11-forwarding. On the client machine, the remote GUI is actually as "local" as it can be. My KDE Plasma doesn't even distinguish X11 forwarded Cinnamon windows from local KDE ones in the Alt-Tab interface.
Detour: Freedesktop D-Bus
Really briefly, D-Bus is an RPC (Remote Procedure Call) framework in object-oriented style. It's used extensively on linux desktop (but far not only). For some examples, the NetworkManager provides a dbus service; it's relatively easy to write an app talking to it over dbus to view and manipulate those network connections, or get callbacks when system connectivity changes. Desktop notifications (those popups from email, messengers, browser apps, etc) are a widely integrated org.freedesktop.Notifications D-Bus service. Ayatana Indicators (tray icons) work over D-Bus too. There's much more.
It makes perfect sense to provide the extension-point for accessibility assistive-tech on D-Bus, too.
Having written code that works with D-Bus, I can tell 100% without doubt, that this error message talks about a D-Bus method call failure:
... the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Combining the above, I can guess why export NO_AT_BRIDGE=1 helps in my case. I'm X11-forwarding a Cinnamon (GNOME derivative) application into a KDE desktop. It'd be silly to expect D-Bus instances of the two desktops to magically connect, X.Org isn't coupled to D-Bus AFAIK. Thus, I hit some obscure corner-case in "AT_BRIDGE" (AccessibilityToolkit Bridge?) of GTK... whatever that is. Disabling it works around the issue for me.
Not sure, of course, how much of this applies to the issue in original question. But, there you go, a bit of context about the apparently related moving parts. HTH
