Interaction Support — runtime interaction support for high-stakes web tasks
Skip to content
Interaction Support Start a conversation

Runtime interaction support · client-side architecture

Exactly as much help as the moment calls for.

Struggle detection

Interaction Support detects real struggle on a page and responds at the lowest level that resolves it.

Escalation

Assistance moves up a defined scale — from a quiet cue to a guided step.

Human-in-the-loop

More autonomy always means more confirmation.

Privacy by design

Nothing typed is stored, and nothing personal leaves the device.

Two layers of inference

Rules where safety matters, a language model where language does.

A research project validating an interface architecture through documented sessions with adults 65+. Peer-reviewed at IEEE SoutheastCon 2026. Not yet a public product.

Interaction Support is a client-side architecture that escalates assistance from observation to supervised execution (L0–L4) only when it detects that a person is struggling with a high-stakes web task with human confirmation at every step.

Adults 65+ are the validation population — the architecture responds to interaction difficulty, not age.

The gap

Three neighboring disciplines each cover part of the problem. None covers the moment.

Interaction analytics sees the moment but doesn't help. Conformance tooling corrects page properties but doesn't see the moment. Autonomous browser agents act, but without reading the moment. Interaction Support is the layer where detection, structure, and action are bound by a single scale.

Conformance standards assess properties of a page — contrast, labeling, structure, keyboard operability. None of them measures whether a person actually finished what they came to do; a fully labeled form can still be abandoned halfway.

Commercial browser agents have converged on binary full autonomy. The missing layer is graduated, human-in-the-loop escalation that begins only at detected difficulty.

How it works

Interaction Support combines two kinds of inference. Struggle detection runs on rules defined in advance — auditable, reproducible, and not learned from data. Above it, a language model interprets what the current step is asking for and explains it in plain terms. What can be executed is fixed in advance, at every level.

  1. 01

    Reads the page’s structure

    Interaction Support builds a semantic interaction graph of the page in front of the person — what the controls are, how they relate, what the task shape is. It reads the browser's own structural tree first, degrading gracefully, so a partially annotated page still yields a usable structure.

  2. 02

    Detects struggle in real time

    The behavioral signal layer reads dwell, backtracking, repeated focus cycling, and abandonment signatures. Struggle detection is local-only and privacy-safe: zero network calls, and nothing the person types is stored.

  3. 03

    Escalates along a defined scale

    Assistance moves up the autonomy scale rather than arriving all at once, with a human in the loop at every level. Escalation is driven by what is happening in the moment, not by a profile set in advance. The person can decline or dismiss assistance at any level, and step back down at any time.

The autonomy scale

L0 — Observation
The layer watches the interaction and does not intervene.
L1 — Perceptual aid
A perceptual cue marks the control the person is stalled on.
L2 — Summarization
The current step is summarized in plain language.
L3 — Voice interaction
The person can ask about the step and hear the answer.
L4 — Supervised agentic action
A single step is executed only after the person confirms it.

Architecture

How the layers separate

Two layers of inference

Struggle detection runs on rules defined in advance — observable signals, thresholds set before the session, nothing learned from data. Above it, a language model interprets what the step is asking for.

The model never sees the person

What goes to the model is the page’s interaction graph — roles, relationships, available actions. Not keystrokes, not form contents, not anything the person typed.

The action layer is fixed

What can be executed is defined in advance, not generated. A single step runs only after explicit confirmation, and it is always reversible.

Deterministic where safety matters. A model where language does.

What Interaction Support is not

01

Not analytics. Analytics reports struggle after the fact. Interaction Support acts on it in the moment, on the person’s side rather than the site owner’s.

02

Not a page-remediation layer. Interaction Support doesn’t rewrite or skin the page. It reads structure that is already there and offers help only when needed.

03

Not an autonomous agent. Interaction Support never acts without a confirmed step. The level of assistance is set by detected difficulty, not by a default.

Why we validate with adults 65+

The tasks that moved online first are the ones with the least room for error: benefits enrollment, plan comparison, medication scheduling, transfers. For adults 65+, these are routine and consequential at the same time, and the offline channel that used to back them up has largely closed.

That makes this the clearest place to measure whether graduated assistance changes outcomes: the difficulty is real, the stakes are real, and completion is unambiguous. What the architecture responds to is interaction difficulty, not age — the same signals appear under fatigue, unfamiliarity, or time pressure in any population.

How this gets validated

Interaction Support is evaluated through documented validation sessions with a validation population of adults 65+ on self-directed high-stakes tasks. Sessions use a sandboxed task replica rather than live accounts — no real credentials, no personal records, no health data.

The design is two-wave: an initial wave calibrates detection thresholds, and a second wave of documented sessions measures whether task completion changes. Participants complete the same task without and with the system.

Instrumentation is privacy-safe by construction. Session data is written locally in a structured log with no network calls.

Current status

Prototype
v0.4.2, deposited on Zenodo
Components
semantic interaction graph reader (ARIA and implicit roles); deterministic difficulty detection; L0–L4 escalation state machine; privacy-preserving instrumentation (local log, no network calls)
Peer-reviewed publication
IEEE SoutheastCon 202610.1109/SoutheastCon63549.2026.11476193
Software deposit
10.5281/zenodo.22021075
Study protocol
10.5281/zenodo.22021551
Validation wave 0
threshold calibration, complete — conformance gradient confirmed across live portals
Validation wave 1
documented sessions, in progress

The architecture is being validated in the field. Here is what that involves.

PARTNER WITH US

Working with older adults on high-stakes digital tasks?

Organizations that already work with adults 65+ — libraries, aging-services nonprofits, community centers, and digital literacy programs — can host documented validation sessions on the high-stakes tasks their visitors bring in.

Nothing is installed on your systems

Sessions run on a laptop the researcher brings.

No real accounts, no personal records

Participants work on a sandboxed replica task.

What a session is, from your side

A one-on-one, 35-minute guided session where a participant works through a real high-stakes web task — the kind your visitors already ask for help with. You provide a room and help us reach people who'd want to take part. We bring everything else: the materials, the consent process, and the researcher's time.

Answers that help you decide with confidence

Need help?
Get in touch with us

Contact us

{{ para }}