AccessPath

Plan walks around mapped stairs and barriers, review access warnings, and report obstacles. AccessPath combines mobility-aware routing, opt-in GPS guidance, and saved journeys.

Comment

Inspiration: a short route is not always a usable route

A staircase, high kerb, narrow passage or temporary blockage can turn an ordinary trip to a library, classroom or community building into a detour. AccessPath explores a practical question: what if a walking planner explained the barriers it can identify, and was equally clear about what it does not know?

What is the specific problem, and how do we know it is real?

The problem is the gap between a short pedestrian route and a route that fits someone's mobility needs. The CDC identifies steps and curbs as physical barriers that can prevent people with mobility impairments from using sidewalks or entering buildings. This is published background evidence, not a survey conducted for this project. Source: CDC, Disability Barriers to Inclusion.

AccessPath's reproducible campus examples show the routing consequence: filtering a stair shortcut changes the available path, and missing access attributes can make a strict route unavailable. The campus is deliberately synthetic. The real-world integration has been exercised between public Torrance City Hall/library map points, but that checks the software and provider connection, not the physical accessibility of those paths. No interviews, school partnership, field survey or measured community impact are claimed. A small, consented local pilot is the next validation step.

What AccessPath does

  • Compare routes: the synthetic campus offers shortest, confirmed step-free and exploratory modes. Explanations and written itineraries expose route tradeoffs and missing data.
  • Plan a real walk or roll: search for places, select map points, enter coordinates or explicitly choose the current location. The wheelchair profile excludes mapped stairs and ferries and requests supported slope, width, kerb and surface limits. Reviewed obstacle areas are avoided, and returned geometry is checked against them.
  • Review uncertainty: ramps may be included. Missing ramp and access coverage stays unknown; it is never displayed as zero barriers or a verified route. Access warnings must be reviewed before guidance starts.
  • Follow the journey: opt-in foreground GPS updates the map and next step, with optional spoken directions and separately enabled off-route recalculation. Stop clears tracking. Imprecise or stale fixes do not trigger automatic reroutes.
  • Remember useful routes: save route snapshots, add names and tags, mark favorites and search the browser-local library.
  • Report obstacles anywhere: choose a public location and explicitly consent to sharing it. Reports persist pending protected moderator review; an unreviewed report does not silently become a trusted route fact.
  • Connect other travel modes: driving, cycling and transit open actual Google Maps directions. These are external handoffs, not an invented in-app timetable or accessibility guarantee.

How it was built

The application uses Next.js App Router, React, TypeScript and Tailwind CSS. Leaflet/React Leaflet render the maps; Motion handles selected interface transitions. Small interactive CSS 3D ramp, stair and kerb illustrations explain access considerations with reduced-motion alternatives.

The campus engine filters graph edges before deterministic Dijkstra routing with a binary min-heap. Real-world planning uses OpenStreetMap-based services: Photon place search, OSRM walking routes and an authenticated HeiGIT/openrouteservice wheelchair profile. Provider calls and credentials remain server-side. Zod validates requests; Drizzle and libSQL/Turso persist reports and shared request gates. Moderator changes require server authentication. Saved journeys remain local to the browser, and no GPS movement history is stored.

Challenges and what was learned

Public Overpass requests timed out in local and hosted checks. The application retained an explicit error rather than substituting an unchecked route, and the authenticated wheelchair provider was connected instead. Its incomplete optional access details are shown as unknown; unsupported strict no-ramp/full-data options are disabled with an explanation.

A production Git build also exposed an overly broad ignore rule that excluded source fixtures along with the local database directory. Anchoring that rule preserved the source data and restored the build. Responsive map testing found clipped endpoint markers after resizing; route bounds now refit when the container changes size.

The central lesson was that access-aware routing depends as much on honest uncertainty and maintained evidence as on calculating a path. Report approval is separate from a complete access survey, and a passing software test is separate from a safe real-world journey.

Accomplishments and verification

The released implementation passed lint, TypeScript and production build checks, 159 unit/integration tests, and 49 browser tests across Chromium and Firefox. Desktop, tablet and mobile states were inspected, including keyboard and reduced-motion flows. Automated accessibility checks found no violations in the exercised states; this is not a full accessibility certification.

A hosted wheelchair-profile request returned 440.1 metres and 11 directions between public test points. GPS movement tests used simulated browser positions, not a real-device field trial. The public app and source are available below.

What's next

Pilot one small real area with community participants who choose to take part. Collect permitted pathway measurements, test the interface with assistive technology, review routing failures and define how reports are maintained and corrected. Improve provider coverage before widening the current access-aware limit of endpoints up to 3 km apart.

Browser guidance currently requires the page to remain open; locked-phone or background navigation is not guaranteed. Unmapped barriers, outdated conditions and missing measurements remain possible. AccessPath is a prototype for informed planning, not emergency guidance or field-verified accessibility.

AI assistance and attribution

OpenAI Codex assisted with architecture, implementation, synthetic fixtures, documentation, testing and submission drafting. The project direction included mobility preferences, ramp warnings, privacy, saved routes and interactive explanatory visuals. UI UX Pro Max guidance and the local 21st design-context workflow informed the interface; 21st catalog retrieval was unavailable, so no downloaded 21st component or hosted generation is claimed. OpenStreetMap contributors and routing providers supply external map data. Manrope and Inter font license files are retained in the repository.

Try it

Built With

Share this project:

Updates

Submission history