Selenium owns the page DOM. The accessibility tree owns the OS. Pick based on where your workflow boundary actually sits.

Selenium was built for one job: end-to-end testing of a single web app. The W3C WebDriver protocol owns the page DOM and nothing else. RPA workflows in production span more than one app. A claims intake reads a PDF, pastes data into a desktop policy admin system, copies a quote ID, opens a portal in Chrome, attaches the PDF through the native file picker, and ends in a Save As dialog. Selenium sees one of those steps. The other six need a different tool, which means you wire AutoIt or pywinauto next to Selenium and now the workflow file is two languages with no shared selector model. The accessibility tree approach handles all seven steps in one binding because Microsoft UI Automation surfaces the browser DOM and the OS chrome through the same tree.

UiPath does ship both, but as two separate activity libraries (UIPath.WebAutomation and UIPath.UIAutomation) that emit different selector formats. A workflow that crosses the browser-desktop boundary has to switch activity sets, which means two selector schemas, two debugging surfaces, and two maintenance code paths. A modern accessibility-tree agent reads the tree directly through Microsoft UI Automation, which already covers the browser content because Edge and Chrome expose their DOM through UIA for screen readers. One binding, one selector schema. The fragility of UiPath cross-boundary workflows is what drives a lot of the migrations we see; see the breakdown in the UiPath alternative guide linked below.

Yes, because Chromium publishes its render tree through the OS accessibility binding. On Windows, Chrome exposes a UIA tree mirroring the DOM (the same tree NVDA and Narrator read). Every input, button, link, and ARIA-labelled region is reachable from the desktop-side tree. The Mediar runtime prefers browser scripts when the focused element is in a browser process (mcp_converter.rs:443-446, the prefer_browser_scripts flag is true by default) because JS clicks are faster and more deterministic for in-page interaction. When the click target leaves the browser (file picker, OS dialog, downloads bar), the same converter falls through to UIA at mcp_converter.rs:862. Same workflow file, two execution layers, no developer hand-off.

Per call, yes, slightly. A UIA tree walk on a complex Windows app is in the tens of milliseconds; a Selenium findElement on a focused page is in the single digits. At workflow scale this rarely matters because the bottleneck is the app under automation, not the binding. A claims-intake step that types into SAP, waits for a server round-trip, and tabs through five fields spends 200 ms in UIA calls and 12 seconds waiting for SAP. The latency that does matter, an LLM call on every step, is the one to watch. Mediar's executor at crates/executor/src/services/typescript_executor.rs has zero LLM calls in the replay loop; grep for openai, gemini, anthropic, or claude in that file and the count is 0.

Architecturally, no. Playwright is faster and has nicer ergonomics, but the boundary is the same: the page DOM through CDP or a browser-specific driver. The moment the workflow leaves the browser, Playwright is in the same position Selenium is. The accessibility tree is the only mainstream Windows binding that crosses the boundary in one selector schema. If your workflow is genuinely browser-only and never touches a file picker, downloads bar, OS sign-in dialog, or desktop app, Playwright is the better web tool. If any step leaves the browser, you want UIA.

The recorder reads the process name of the focused window at the moment of the click. If the process is chrome.exe, msedge.exe, or another known browser binary (the list is in apps/desktop/src-tauri/src/mcp_converter.rs around line 105), the click is normalized as a browser_click event with both UIA coordinates and a CSS selector emitted by the Terminator Bridge extension (Chrome Web Store ID ajnnhmahjbbohenflacjkbdeohicnbmg, registered in chrome_extension.rs:9). Otherwise it is a button_click event with UIA selector only. The list of normalized events is in recording_processor.rs around line 248: button_click, browser_click, text_input_completed, browser_tab_navigation, application_switch, file_opened.

Yes. Those systems expose UIA elements because they have to for accessibility compliance. SAP GUI publishes its controls through a UIA provider; Jack Henry and Fiserv terminal emulators run inside Win32 host windows that expose Edit and Button controls; Epic Hyperspace exposes its panels through the same provider. The Mediar binding reads them directly. Selenium cannot reach any of these systems because none of them are browsers. This is the whole reason the accessibility tree approach exists for enterprise RPA rather than for new SaaS workflows.

Selenium IDE records DOM events: click on selector, type into selector, select option. A real RPA workflow records intent across processes. A claims-intake recording captures a PDF open in Acrobat, a copy from a specific field, a paste into a desktop admin system, a tab switch to Chrome, a click on a Save button that opens a file picker. Selenium IDE sees zero of those events because none of them happen inside one page. A purpose-built RPA recorder sees all of them because it hooks the OS accessibility events, not the browser DOM events. The Mediar recorder, apps/desktop/src-tauri/src/workflow_recorder.rs, is built on this distinction.

Selenium scripts break on framework upgrades, virtualization changes, A/B tests, and class refactors. Maintenance hours scale linearly with the number of pages automated. Accessibility-tree workflows mostly survive a label rewrite, dark mode, panel reorder, and AutomationId churn because the four-strategy match cascade in focus_state.rs:168-196 walks automation id, then window plus bounds, then visible text, then window focus before failing. The maintenance hours go down as the cascade absorbs more drift. The first thing a buyer should compute is the maintenance line in their existing RPA contract; that is the line that compresses when the binding changes.