Inspiration
A useful accessibility preference still leaves practical questions: does the step-free entrance cover the whole route, and how will someone in a quieter waiting area know they are being called? AccessRoute explores that preparation gap. Health and care passports already exist; this prototype focuses on rehearsing a visit, keeping the scope of a self-recorded confirmation visible, and controlling what leaves the browser.
What It Does
AccessRoute is a patient-controlled, nonclinical accessibility visit rehearsal using fictional examples. Edit communication, sensory and mobility requests, then work through arrival, waiting and consultation. Each stop offers an example situation and a phrase to practice. An illustrative tension panel keeps relevant questions nearby.
The confirmation ledger separates a request from a not-yet-confirmed arrangement and from a self-recorded, unverified confirmation or unavailability record. Saving those records requires a source and scope. Revising a request clears its old evidence and resets only the affected rehearsal stops.
Sharing starts with nothing selected. Choose individual requests, preview the exact note, then download text or print/save a PDF. Unselected requests, rehearsal answers and progress are excluded. The app does not send the note to anyone.
How Built
The browser application uses React, Vite and Lucide React, with original interface and route illustrations. A small deterministic model handles request revisions, related-stop invalidation, saved-state validation and allowlisted export. The example tension checks are explicit category-based rules, not an AI interpretation of arbitrary text. State stays in unencrypted browser localStorage; the application has no backend, login, analytics, remote fonts or runtime AI.
AI assisted implementation and bounded code review. It does not process prototype inputs. Original application code is MIT-licensed, with dependency notices included in the repository.
Challenges
The difficult work was preserving boundaries across ordinary interactions: a new request must not inherit stale evidence; a completed rehearsal must not look like a confirmed service; and printing from another screen must not disclose unselected information. Repeated and interrupted flows also exposed a keyboard-focus issue when a ledger editor closed. The current build restores focus to the control that opened it after Save or Cancel.
Accomplishments
The prototype completes a real end-to-end rehearsal and selective-sharing workflow without an account or application backend. Exact-main verification passed 20 model tests, 26 browser tests and six privacy PDF cases in both development and production modes. A separate hosted check passed three keyboard-focus regressions, and all 13 public deployment files matched the verified artifact. These are automated engineering checks, not a claim of complete accessibility or clinical effectiveness.
Learned
Evidence needs a scope, not just a positive status. Revision invalidation and export privacy need to be tested at the UI and document boundary, not only in the data model. Keyboard focus is also part of finishing an action: removing a form should not leave its user without a meaningful place to continue.
Next
The next step is consent-based usability research with people who have accessibility needs and with care-service staff, followed by revision of the fictional scenarios and broader assistive-technology testing. No such user study has been completed. Any real-world pilot would need its own privacy and clinical-context review; the current prototype is for synthetic examples only.
Boundary Note
Unvalidated nonclinical prototype. Synthetic information only. No diagnosis, medical advice, clinic contact, verified availability, guaranteed accommodation, clinical outcome or user-study claim. Browser storage is unencrypted, and the static host can see ordinary web requests.
Log in or sign up for Devpost to join the conversation.