Passage

Make neighbourhood access barriers visible, compare surveyed routes, and turn local observations into a practical repair plan.

Comment

Inspiration

A route that looks short on a map might contain steps, uneven paving or a blocked crossing. For wheelchair users, older residents and people pushing prams, these details affect access to schools, clinics and markets. We chose neighbourhood accessibility because a small, well-documented repair has a clear local audience.

WHO estimates that 1.3 billion people, about one in six worldwide, experience significant disability. This is a global figure, not a measurement of our community. Research on sidewalk barriers also shows that different mobility-device users experience the same street differently.

What it does

Passage is a working local-first accessibility audit workspace. It connects three tasks: record a street barrier, compare routes on a surveyed network, and prepare an explainable repair shortlist.

The demo uses six illustrative destinations, nine street segments and four labelled sample observations. It is a schematic neighbourhood, not geographic navigation or real field evidence.

You can:

  • Add a validated observation and prevent a duplicate open report for the same barrier and segment.
  • Move a report through unverified, reviewed locally and resolved states.
  • Compare distance-only and step-free routes. Step-free mode excludes steps and blocked segments.
  • Inspect unsurveyed segments instead of receiving an unsupported access guarantee.
  • Adjust an effort budget and see an explainable repair shortlist.
  • Export JSON, import a validated workspace, and download a printable community handoff.
  • Continue using the application shell offline after the first successful visit.

How we built it

The website uses browser-native JavaScript modules, HTML and CSS, with a purpose-built SVG network and a CSS perspective neighbourhood illustration. No paid AI API is required to use the app.

The graph engine applies Dijkstra's algorithm. Step-free search weights combine distance, reported barrier penalties and an unknown-coverage penalty. Displayed metres are physical edge lengths, not the weighted search score.

Repair priority is (severity × 3 + essential access × 2) ÷ effort. A greedy ranking creates a shortlist within the budget. It is transparent, but not a globally optimal repair programme. Effort points are subjective planning units, not construction prices.

The local storage and import paths use the same schema validator. Inputs are limited to 500 records and 1 MB import files. Objects are reconstructed from allowed fields, and user text is escaped before rendering. Vercel serves the static application with a restrictive content security policy and privacy headers.

The demo video uses authored frames and actual application captures, assembled with FFmpeg at 1920×1080. Its narration uses ElevenLabs River. The gallery contains 15 design boards grounded in real interface captures.

Challenges

The hardest design choice was keeping uncertainty visible. A report is not an official inspection. An unknown street is not an accessible street. A ranking is not an engineering decision.

We also chose explicit workspace export over pretending that a local prototype already has shared moderation. Records stay on the user's device. Volunteers transfer them intentionally through JSON files and printable handoffs.

Accomplishments

The prototype includes six responsive views and a complete observation-to-handoff workflow. Nine graph and validation tests pass. Seven further browser security and data-integrity checks pass, including stored HTML injection, safe exports and invalid import preservation. Ten browser workflow checks pass, covering route output, duplicate prevention, local persistence, status changes, repair planning, download, offline reload and mobile width.

These are technical checks. We have not measured real-world social impact, conducted interviews or obtained a municipal endorsement.

What we learned

Accessibility tools need evidence, coverage and user preference, not a single confidence badge. A small app is easier to sustain when its useful core works without accounts, geolocation or paid APIs.

Accessible routing already has important precedents, including AccessMap and sidewalk-mapping research. Passage's contribution is combining local observation management, route comparison and a repair handoff in one low-cost community workflow.

Team

Proposed responsibilities:

  • Adeel Falak Sher: engineering, graph logic and deployment lead.
  • Rauf Khalid: community research, usability review and presentation lead.

These roles are assignments for the team to confirm before submission. They do not claim that either person completed independent interviews or testing.

What's next

Co-design with local mobility-device users. Survey one permitted public corridor. Record independently reviewed measurements and dates. Then add authenticated community moderation, real map ingestion and municipal partnerships.

Honest scope and assistance

This is a working local-first prototype, not a citywide production navigation service. Local data is not encrypted at rest. It should not contain names, health information or private addresses. Anyone with access to the browser profile can read local records. No official verification, shared accounts, live satellite maps or cloud database are claimed.

The implementation, visual assets and submission materials were created with AI assistance at the team's request. Human-readable labels, data boundaries and reproducible checks are included for review.

Research

These sources establish the problem. They do not validate Passage's prototype scoring weights.

Watch the demo

https://passage-community-access.vercel.app/demo.html

Built With

Share this project:

Updates

Submission history