AccessPath

AccessPath verifies wheelchair-accessible journeys with attributable evidence, exposes uncertainty, and automatically replans when a critical barrier makes the original route unusable.

Comment

Inspiration

A route can exist on a map and still be impossible to complete. For wheelchair users, one inaccessible entrance, unavailable lift, steep ramp, or unverified restroom can invalidate an otherwise sensible journey. Accessibility details are often scattered across operator and venue pages, may conflict, and can become outdated.

We built AccessPath to explore a more responsible question than “Can I get there?”: “Can I actually use every critical part of this journey, and what evidence supports that conclusion?”

What it does

AccessPath is an AI-assisted accessibility verification and replanning experience. Its focused London pilot evaluates a five-hour wheelchair-accessible journey from Victoria Station to the Natural History Museum, including step-free transport, a café, a museum visit, and accessible restroom facilities.

The default journey initially prefers the museum's East Entrance. AccessPath then finds a meaningful evidence conflict: the entrance depends on a lift, while the curated evidence snapshot includes an official maintenance notice reporting that lift unavailable. Instead of hiding the problem, AccessPath:

  • displays the affected claim and its supporting and conflicting sources;
  • limits the East Entrance to Needs review with 25% confidence;
  • evaluates every supported entrance candidate;
  • automatically selects the step-free Central Entrance;
  • labels the revised route Usable with caveats at 79% because its steep ramp still matters; and
  • preserves source links, evidence dates, freshness, uncertainty, and the reason for the decision.

The experience is genuinely interactive. Adding “I cannot use steep ramps” in natural language—or enabling the matching control—triggers a complete reevaluation. The East Entrance remains blocked and the Central Entrance fails the new requirement, so AccessPath returns an honest no-match result rather than recommending an unusable route.

How we built it

AccessPath is a Next.js and TypeScript application deployed on Vercel at accesspaths.xyz. The interface is built with React and accessible interaction patterns, while secret-bearing model requests run only on the server.

The production deployment uses Featherless with the pinned open-weight Qwen/Qwen2.5-7B-Instruct model. The model converts natural-language requests into structured accessibility constraints. Every model response must pass a Zod schema before it can enter the planning pipeline. Explicit controls and interpreted prose are merged conservatively so that AI cannot silently remove a critical requirement. A Gemini provider is also implemented behind the same boundary, and a clearly labelled deterministic parser keeps the core demo functional when model inference is unavailable or invalid.

We deliberately separated semantic interpretation from safety-critical decisions:

  • AI handles: natural-language constraint extraction.
  • Deterministic TypeScript handles: source attribution, evidence assessment, confidence, critical-requirement enforcement, candidate selection, route acceptance, and fallback behavior.

The evidence graph connects journey segments and places to accessibility claims and attributable sources. Confidence is calculated from visible rules: source authority contributes 55%, claim directness 25%, and freshness 20%, with limited corroboration adjustments and strict contradiction handling. Route confidence is constrained by the weakest critical segment, preventing a dangerous unknown or conflict from being hidden by an average.

The candidate planner has only three outcomes: unchanged, replanned, or no-match. It never selects a blocked candidate merely to produce a successful-looking answer.

Challenges we ran into

Using AI meaningfully without making it the safety authority. Natural language is useful for understanding a request, but an LLM-generated confidence score would be difficult to audit and unsafe to trust. We created a strict provider and schema boundary, then kept evidence, scoring, and route acceptance deterministic.

Representing contradictory and stale accessibility information. A general accessibility page and a feature-specific maintenance notice can both be official while disagreeing in practice. We designed explicit evidence relationships and claim states—Verified, Likely, Conflicting, Unknown, and Inaccessible—so uncertainty remains visible.

Avoiding false success. The planner originally needed more than a preferred route and one fallback. We implemented candidate-based selection so a new requirement can preserve the current route, choose a valid alternative, or return no match when every option fails.

Building a reliable live demonstration. Provider failures, malformed structured output, secrets, and changing external information could undermine the demo. We added schema validation, server-only credentials, deterministic fallback, a versioned curated evidence snapshot, exact dependency versions, and focused automated tests.

Making an accessibility product accessible. The primary flow uses semantic structure, keyboard-operable controls, visible focus, screen-reader status announcements, reduced-motion support, readable labels, and text and icons in addition to color.

Accomplishments that we're proud of

  • Built a complete evidence-to-decision workflow rather than a fixed animation or generated itinerary.
  • Made a real Featherless inference consequential: prose changes a structured requirement and can change the final route decision to no-match.
  • Implemented explainable deterministic confidence and weakest-critical-segment gating.
  • Connected displayed accessibility claims to attributable sources and dates.
  • Made conflict detection produce a visible automatic replan from the East Entrance to the Central Entrance.
  • Added 15 offline scenario and integrity tests plus two opt-in live Featherless tests; all 17 pass.
  • Implemented graceful, honestly labelled fallback behavior for unavailable or invalid model output.
  • Shipped an accessible, responsive interface on a sponsored .xyz domain.
  • Kept credentials out of the client and public repository, with a clean dependency audit and passing quality gates.
  • Used sponsor tools where they strengthened the project: Featherless for production inference, Hawkeye for local architecture traceability, Prelint connected for pull-request review, and .XYZ for the public deployment.

What we learned

We learned that trustworthy AI products need a clear boundary between interpretation and authority. The model is valuable when translating flexible human language into structured constraints, but important decisions become more credible when users can inspect the evidence and deterministic rules behind them.

We also learned that uncertainty is a product feature, not a failure state. Showing that evidence is missing, stale, contradictory, or only likely is more useful than presenting a confident answer that may be wrong. A small, carefully attributed dataset produced a more convincing experience than pretending to support every city and venue.

Finally, accessibility must shape both the product logic and the interface. It is not enough to calculate an accessible route if the person who needs it cannot operate or understand the application.

What's next for AccessPath

The current release intentionally remains a focused London pilot. The next steps would be:

  1. Conduct usability testing with wheelchair users and accessibility specialists.
  2. Add more London journeys only when each critical claim has attributable evidence.
  3. Build a reviewed evidence-ingestion workflow with freshness checks and change detection.
  4. Integrate real operator status feeds where reliable APIs are available, while preserving the distinction between live and curated data.
  5. Support saved accessibility profiles with privacy-conscious controls.
  6. Expand automated accessibility testing and independent manual review.
  7. Research how the same evidence and decision model could support other mobility requirements without collapsing different needs into one generic “accessible” label.

AccessPath does not guarantee that a route is safe or accessible. Evidence can become outdated, so users should confirm critical details with the relevant operator or venue before travelling.

Built With

Share this project:

Updates

Submission history