Ieum — Spatial Accessibility Bridge

• 

  page1

• 

  page2

• 

  Ieum — Overall Architecture 1

• 

  Ieum — Overall Architecture 2

Ieum — Spatial Accessibility Bridge

### Inspiration

Ieum is a Korean word associated with connection, joining, and creating a link between separate things. We chose the name because Ieum connects a traveler, a browser agent, and the spatial facts already owned by a website.

A seat map is not just a list of seat numbers. For many travelers, location is the decision itself: Is the seat near the entrance? Which side of the aisle is it on? What landmarks are on the way? Does it meet a stated access need, and can the traveler verify that answer instead of accepting a summary?

Most accessibility approaches flatten a visual seat map into a table. That may expose row and column labels, but it can lose the spatial relationships that make a seat usable. A traveler who needs a transfer seat and wants to verify the route from the entrance needs more than a seat number.

Ieum is a Spatial Accessibility Bridge. It explores a different model: instead of asking an agent to infer geometry from pixels, screenshots, or DOM layout, the website exposes the structured spatial facts it already owns.

### What it does

Ieum models one independently authored, unbranded synthetic rail car and exposes a complete spatial decision journey through nine stable WebMCP tools:

• a11y.get_layout — orient within the car and inspect reference points;
• a11y.query — find seats by availability, price, position, direction, distance, and access needs;
• a11y.describe — inspect one seat or landmark and its relationships;
• a11y.get_route — receive structured walking directions;
• a11y.compare — compare two to four seats on the same axes;
• a11y.select — add an available seat to a draft decision;
• a11y.get_selection — inspect the current draft;
• a11y.undo — restore the previous draft state; and
• a11y.confirm — open a human-controlled confirmation boundary.

A traveler and an agent can work together through a concrete decision: find an available seat with a needed feature near the entrance, inspect its route, compare it with another candidate, add it to a draft, and review it before confirming.

The tools expose structured facts instead of a one-shot summary: stable references, seat position, side, facing, price, availability, accessibility characteristics, landmarks, route segments, and explicit query criteria.

Routes are sourced in meters. The same geometry can be rendered as feet, meters, or approximate steps, while direction wording can adapt to preference. Walking-speed preferences derive traversal-time estimates without changing the meter-source geometry. When steps are requested, Ieum explicitly identifies them as approximate conversions rather than measured facts.

### Why WebMCP

WebMCP is a strong fit because the site already owns the authoritative spatial model. An external agent should not have to guess where a seat is from a visual grid or scrape labels that were never designed to express spatial relationships.

Ieum uses WebMCP to expose a structured, inspectable contract for spatial decisions. The agent can help the traveler ask better questions and sequence tools, while Ieum supplies deterministic facts, routes, state transitions, and safe confirmation behavior.

Human controls and WebMCP tools share browser-local decision state for highlights, routes, draft selection, totals, undo, confirmation, and the activity log. When an agent requests a route or adds a seat to a draft, the person can see that same decision state in the page.

Most importantly, the agent cannot confirm a decision on the traveler’s behalf. An agent can open the confirmation interaction, but only a person acting in the page can make that same call return confirmed.

### How we built it

We built Ieum as a browser-local system with clear boundaries between spatial data, decision logic, human interaction, and agent integration:

   Authored Spatial Fixture
           ↓
   Pure TypeScript Domain Core
           ↓
   Application State and Use Cases
           ↓
   Accessible Human UI + WebMCP Adapter

   The Ieum demonstrator uses one independently authored synthetic rail car with 60 seats, landmarks, reference points, aisle anchors, and traversable path edges. It is not scraped from a visual map or copied from a real operator.

   The Domain Core resolves stable references, filters and compares seats, derives routes, calculates bearings and distances, and keeps route geometry deterministic.

   The Application layer owns shared decision state: highlights, active route, selected seats, price total, undo history, confirmation status, and a visible activity log.

   The WebMCP adapter declares input schemas, registers the nine a11y.* tools through the
   document.modelContext.registerTool API, projects structured results, maps expected domain failures to structured responses, and records agent-originated calls in the same decision state used by the interface.

   Ieum uses the same application use cases for both human interaction and WebMCP tools. WebMCP is progressive enhancement: when it is unavailable, the human interface still provides a usable decision workflow with search, route inspection, comparison, selection, undo, keyboard-operable seat-grid navigation, semantic labels, live status updates, and a focus-managed confirmation dialog.

   Challenges we ran into

   The hardest problem was not drawing a seat map. It was defining spatial information precisely enough to remain useful when someone cannot inspect the map visually.

   Turning geometry into dependable language. Straight-line distance is not necessarily a usable walking route. We modeled traversable route segments, landmarks, bearings, and counted rows. Geometry stays meter-based; human-readable distance, direction, timing, and approximate-step output are derived at the presentation boundary.

   Preventing false spatial conclusions. A route from one side of an aisle to the other cannot collapse to zero distance simply because both seats share a row. The route must include movement out to the aisle and back toward the destination.

   Keeping person and agent interactions coherent. A separate agent-only workflow could become invisible or confusing.
   We designed shared decision state so route highlights, selections, totals, undo behavior, confirmation status, and tool activity remain visible in one page.

   Making assistance useful without surrendering agency. Selection is explicitly a local draft. Confirmation remains pending until the person responds, and cancellation or timeout restores the editable draft. This demo does not book tickets, charge money, or connect to live inventory.

   Accomplishments that we're proud of

   - A complete WebMCP decision journey. The nine tools cover orientation, search, inspection, routing, comparison, draft selection, undo, and human confirmation rather than isolated one-off queries.
   - Structured routes as first-class data. Route segments, landmarks, lengths, bearings, traversal-time estimates, and continuation behavior are available as structured output rather than hidden inside a sentence.
   - Shared decision state, visible in one page. Human controls and agent calls operate on the same route, draft selection, totals, undo history, confirmation state, and activity log.
   - A real human-control boundary. The agent can prepare a decision, but it cannot make the page return confirmed without a person acting in the interface.
   - Accessible without an agent. Ieum keeps a keyboard-operable grid, semantic seat labels, status announcements, route
   controls, and confirmation behavior available even when WebMCP is unavailable.
   - A reusable direction for spatial interfaces. The current implementation is rail-only, but the contract separates stable spatial facts from the specific fixture. The same approach can inform future room, venue, or other pre-selection spatial decisions.

   What we learned

   We learned that accessibility support is stronger when people can interrogate underlying facts instead of receiving a condensed answer they cannot verify. Stable references, explicit criteria, structured errors, route segments, and consistent comparison axes give a traveler something concrete to question and evaluate.

   We also learned to separate source facts from presentation. Distances belong in measured meters; feet, direction phrasing, and approximate steps belong at the rendering boundary. This lets one spatial model adapt to different preferences without rewriting the geometry.

  Finally, we learned that trustworthy assistance needs a stopping point. The ability to review, undo, cancel, and personally confirm is not a final UI detail. It is part of the product model.

  Our accessibility-oriented implementation and automated engineering checks are not a substitute for participant research. We have not yet conducted a direct study with blind and low-vision travelers, and we treat that as an important limitation rather than a claim of validation.

  What's next for Ieum — the Spatial Accessibility Bridge

  Our next step is to validate the interaction model with people who navigate spatial decisions nonvisually. Their feedback should shape the vocabulary, route presentation, comparison flow, and confirmation language before the project expands into real operational contexts.

  From there, we want to broaden Ieum beyond this single synthetic rail-car demonstrator while preserving its principles:

  - one reliable spatial source of truth;
  - deterministic, structured outputs instead of visual inference;
  - a fully usable non-agent path;
  - shared human-agent decision state; and
  - a human-controlled final decision.

  Future work may explore richer routing and additional spatial domains, but only with appropriate real-world data, operational constraints, and participant-informed validation.

Built With

• accessibility
• aria
• chatgpt
• computing
• development
• human-in-the-loop
• next.js
• openai
• playwright
• react
• reader
• screen
• spatial
• typescript
• vinext
• vitest
• web
• webmcp