Accessible Transit: Getting There and Back

Inspiration

Most transit planners reduce wheelchair accessibility to one answer for an entire station. The problem is that elevators serve specific platforms, not entire stations. A station can be accessible in one direction and inaccessible in the other. A rider may be able to arrive, then discover there is no step-free way to board the train home.

At NYPL’s Built for NYC AI Hackathon, we asked: Can a subway rider know, rather than guess, whether a trip is accessible both ways?

What it does

Accessible Transit analyzes subway accessibility at the platform and direction level.

The app: Warns riders about barriers on the outbound and return portions of a trip. Identifies one-way accessibility gaps where someone can arrive but may not be able to return. Incorporates official MTA elevator outage records. Suggests nearby accessible stations, prioritizing alternatives on the same subway line. Includes subway and bus options.

Uses NYC Open Data to assess nearby curb ramps against published ADA standards. Explains uncertainty instead of hiding potentially useful routes.

Our guiding rule is simple: warn, never block. Riders may have options the data cannot see, such as a companion, a bus connection, another entrance, or a different transfer. The app provides context so the rider can make the decision.

How we built it

We combined several public datasets: MTA GTFS schedule data. MTA Subway Stations data, including northbound and southbound ADA status. MTA Elevator and Escalator outage records.

NYC Open Data for 217,679 pedestrian ramps and their accessibility measurements. A Python pipeline resolves accessibility for each directional platform and creates an augmented GTFS feed. We joined the datasets using published station identifiers instead of fuzzy name matching. A FastAPI service makes the processed data available to the application. The front end was built with React, TypeScript, and Vite.

We used AI-assisted coded prototyping to move quickly from product decisions to a working experience we could test. Human judgment still guided the data rules, accessibility decisions, validation, and product scope. The interface includes keyboard navigation, screen-reader support, visible focus states, adjustable text sizing, clear written status labels, and color-independent warnings.

Challenges we ran into

One value with two meanings The MTA and GTFS both use the value 2, but they mean different things. In GTFS, 2 means boarding is not possible. In MTA data, it means the station is partially accessible. Combining them would cause a trip planner to interpret usable stations incorrectly. We preserved both values separately and applied GTFS accessibility at the directional platform level.

Incomplete outage information The elevator feed does not always identify which direction an elevator serves. Rather than presenting uncertain data as precise, we apply a conservative warning and explain the limitation.

Filtering versus informing Strict accessibility filtering can return zero trips, even when a rider may have a workable option. We decided to show available routes with clear warnings instead of removing them automatically.

Demonstration data versus live service The public planner requests official MTA outage records when it opens. Its trip schedule and station set remain demonstration data. We label that limitation clearly. A rider-facing release would require a hosted backend and scheduled data updates.

Accomplishments we are proud of

Resolved directional accessibility across all 496 subway stations. Joined all 496 station records and 193 elevator-equipment records using exact identifiers. Identified eight platforms where a rider may be able to arrive but not return the same way. Found that those eight platforms affect 22,937 of 77,236 scheduled trips. Evaluated nearby curb ramps against measurable ADA requirements. Built a working data pipeline, API, and accessible web experience during the hackathon. Designed the app to communicate risk without taking control away from the rider.

How we worked together

Jacqueline Gordon brought an accessibility-first interaction lens. She led features including text-to-speech and adjustable text sizing. Hillary Esposito led product strategy, data logic, accessibility decision-making, and AI-assisted coded prototyping. Together, we translated complex transit data into information riders can understand and act on.

What we learned

Accessibility cannot be represented honestly as a single station-level flag. We also learned that incomplete data requires more explanation, not more confidence. When a system cannot answer a question precisely, the interface should communicate that uncertainty clearly. AI-assisted development helped us explore, build, and test quickly. The harder work still required human judgment: defining the problem, interpreting conflicting standards, checking the data, setting boundaries, and deciding what the product should never claim.

What’s next

Deploy the FastAPI service to a public host. Rebuild accessibility data on a schedule as outages change. Add real-time arrival information. Identify the specific accessible entrance for each station. Improve transfer accessibility details within station complexes. Test the experience with wheelchair users and people with other mobility disabilities. Conduct additional testing with screen readers and other assistive technology.