Replacing RPA with accessibility automation is an input-layer swap, not a selector remap.

For Windows desktop workflows on legacy systems with no API (SAP GUI, Oracle EBS, Jack Henry, Fiserv, FIS, Epic, Cerner, eClinicalWorks, mainframe terminals through emulators), yes, and the architectural difference is real. RPA's input layer is selector authoring: a developer or analyst sits in Studio and tunes XPath-style selectors per control until the workflow replays cleanly. Accessibility automation's input layer is recording plus a normalization step that discards mouse coordinates and raw keystrokes and keeps six intent events. The recorder lives at apps/desktop/src-tauri/src/recording_processor.rs in the open-source Terminator monorepo; the meaningful event filter is at lines 250 to 260. Replacing the input layer (rather than swapping vendor selectors) is what makes this honest as a category, not a reframe. Where this is not a fit: stable browser-only workflows on modern SaaS where an OpenAPI integration beats both RPA and accessibility automation on cost and reliability.

None of the artifacts transfer. The .xaml files, the published NuGet packages in Orchestrator, the OCR resource paths, and the asset queues do not import into an accessibility-automation runtime. What does transfer: the operational knowledge of which 200 workflows are actually worth keeping (in our experience the answer is usually 60 to 120 of them, the rest were built when you had spare licensing capacity), the production credentials and environments, and the input data. The honest path is parallel. Keep stable UiPath workflows running on the workflows whose selector maintenance has been quiet for more than a quarter. Re-record the workflows where selector authoring has stalled new development for three months or more, where Patch Tuesday has been breaking the same Robot every month, or where the queue of new automation requests is permanently longer than the team that ships them.

Two reasons sit in the source. First, the recorder discards everything that is not intent. Mouse moves, raw keystrokes, scroll deltas, and hover events are filtered out before authoring; only six event types survive (button_click, browser_click, text_input_completed, browser_tab_navigation, application_switch, file_opened, defined at apps/desktop/src-tauri/src/recording_processor.rs:250-260). The author does not waste hours tuning a recorded sequence to ignore the user's cursor wandering. Second, the runtime does not bake one selector per click. It walks a multi-strategy match cascade in apps/desktop/src-tauri/src/focus_state.rs lines 168 to 196: try automation or accessibility id, then window plus bounds, then visible text, then parent window focus. Most enterprise UI patches (a label rename, a panel reorder, a control id change) are absorbed by one of the first three strategies. RPA's Studio resolves a single recorded selector and throws on miss; the same UI patch that breaks a UiPath Robot does not break the executor.

The runtime is one Rust crate, the executor at crates/executor/src/services/typescript_executor.rs in the open-source github.com/mediar-ai/terminator monorepo. Run `wc -l` against that file and the result is 871 lines. Run grep against it for any LLM provider name (gemini, openai, claude, anthropic) and the count is zero. The executor reads the TypeScript workflow file off a Postgres queue, calls MCP execute_sequence on a separate process, and the Terminator SDK drives Windows UI Automation through the uiautomation Rust crate (Cargo.lock pins it at version 0.22.2, the same accessibility surface a screen reader uses on Windows). The model lives in the authoring path, where Gemini Vertex AI converts a recording into a workflow file. After authoring, no model is on the hot path. That is the property that makes audit possible and that makes runtime cost predictable.

Power Automate Desktop reads UIA properties at recording time and falls back to image matching when UIA does not return a usable selector. The mixed mode is what causes flow drift: a recorded action set that tested fine on the developer's machine fails on production because the image fallback is sensitive to font rendering, dark mode, and resolution shifts. Replacing PAD means re-recording in an accessibility-only path with no image fallback, which sounds restrictive but isn't, because Windows enterprise apps that ship with accessibility compliance (which the apps in scope all do, because regulators required it) expose enough UIA elements that fallback is rarely needed. If a control truly has no accessibility surface, that is a sign you should not be automating it; the same workflow will fail under PAD too, just nondeterministically.

Yes. Object Cloning captures element properties at recording time and bakes them into selectors that the Bot Runner resolves at replay. It is the same selector-at-author-time pattern as UiPath, with a different file format. The architectural delta against accessibility automation is identical: a single recorded selector resolved against the live tree at replay versus a multi-strategy cascade walked from the focused element outward on every step. The migration story is also identical: TaskBots and MetaBots do not transfer, workflows get re-recorded once, the new artifact is a TypeScript workflow file, and runtime cost shifts from per-Bot-Runner licensing to per-minute usage at $0.75 per minute of executor time.

Application Modeller spies once at modelling time, persists the spied attributes as part of the VBO, and the Runtime Resource resolves the persisted attributes at replay. The spy is at the accessibility layer; the resolution is single-shot. Blue Prism's failure mode at scale is the same as UiPath's: when a control's spied attributes drift (an automation id renames, a class refactors, a parent window restructures), the action throws and a developer reopens Application Modeller, re-spies, and republishes the VBO. Accessibility automation reads the live tree on every step instead of resolving a persisted snapshot, with the four-strategy cascade absorbing most attribute drift silently. The governance story (audit logs, validation rules, role-based access) carries over in concept; the implementation does not. SOC 2 Type II and HIPAA compliance are in place on Mediar's side, but the artifacts and the monitoring tooling are different.

The 871 lines are the executor service that pulls workflows off a Postgres queue and calls MCP execute_sequence. The MCP server is a separate service that wraps the Terminator SDK; the SDK itself is a published Rust crate (terminator-rs). The recorder is a Tauri desktop app at apps/desktop in the same monorepo, with the recorder module at apps/desktop/src-tauri/src/workflow_recorder.rs and the tree-capture module at apps/desktop/src-tauri/src/ui_tree_capture.rs. The authoring layer (recording to TypeScript workflow file) runs in modal_apps and uses Gemini Vertex AI. The point of citing the 871-line executor is that the determinism property lives in one small file the buyer's RPA Center of Excellence can audit before signing. RPA vendors do not generally let buyers audit the equivalent file, because the runtime is closed source and the resolver code path is not documented.

UiPath enterprise contracts at the RPA Center of Excellence level commonly land between $100K and $500K-plus for the first year, including Studio seats, attended and unattended Robot licenses, and Orchestrator tiers. Power Automate Desktop is bundled into Microsoft 365 plans for low-volume use; the per-Bot premium tier and Process Mining add-ons compound at scale. Automation Anywhere and Blue Prism are quoted similarly to UiPath at the same volume tier. Mediar charges $0.75 per minute of executor runtime, with a $10K turn-key program fee that converts to credits with a bonus, so the program fee is effectively prepaid usage. A workflow that runs ten minutes a day for a year costs roughly $1,575 in runtime. The mid-enterprise comparison the website cites lands at about 20% of UiPath cost; savings shrink at extreme concurrency and grow on long-tail workflows that selector-based RPA cannot keep alive.

Probably less of it. The accessibility-automation argument compounds with workflow count: a multi-strategy match cascade saves the most time when there are fifty workflows touching the same UI estate that all break together on a Patch Tuesday. With under twenty workflows, the operational delta is real but small, and the migration cost (re-recording everything once) is paid against a smaller benefit. Where small estates do benefit: when one of the twenty workflows is the one that has stalled for six months because the Studio team cannot find a stable selector for a particular SAP screen. That single workflow is worth re-recording in a few hours rather than waiting another quarter on selector engineering.