OpenAccessibility
All posts
VisionMay 1, 2026·4 min read

The GTFS Moment for Accessibility

Transit became dramatically more useful once GTFS standardized transportation data. Accessibility needs a similar breakthrough: a shared, machine-readable layer for physical spaces.

By The Open Accessibility Team

Isometric illustration of a white city with green accessibility pins connected by a routed path.

In 2005, transit in most cities worked like this: each agency published a PDF of routes and timetables, hoped riders could read it, and accepted that trip planning across systems was somewhere between difficult and impossible. There were dozens of mapping products. None of them could tell you when the next bus was coming.

Then a small team at TriMet in Portland and a couple of engineers at Google agreed on a format. A folder of CSV files, a short specification, a way for agencies to publish their schedules in a way that software could read. They called it the General Transit Feed Specification. GTFS.

Within a few years, every modern mapping product had real-time transit directions. Riders could compare modes, plan trips, and trust the data because it came from the agency itself. Cities that adopted GTFS suddenly became legible to software in a way they hadn't been before.

GTFS did not invent transit. It made transit data interoperable. And that turned out to be most of the battle.

The same story, repeated

Standardization unlocks ecosystems. It is one of the most underrated forces in technology because the standard itself is boring; the explosion of products around it is not.

  • Before GTFS, transit was a thousand isolated systems. After GTFS, transit became a thing software could reason about.
  • Before HTTP and HTML, online information was a patchwork of incompatible protocols. After, it became the web.
  • Before standard package managers, installing a library meant downloading a tarball from a personal homepage. After, ecosystems exploded.

In each case, the standard didn't make the underlying activity new. It made the activity composable. Once anyone could build on top of it without negotiating with each producer individually, an ecosystem grew.

Accessibility data is sitting exactly where transit data sat in 2004.

Where accessibility is now

There is no shortage of accessibility information. There is a profound shortage of accessibility data.

  • Mapping platforms expose a single yes/no flag.
  • Review sites surface accessibility in unstructured comments.
  • Specialized accessibility apps maintain richer datasets, but each in its own format, on its own coverage map.
  • Businesses publish claims on their own websites in their own words.
  • Cities collect compliance data and rarely make it queryable.

None of this is connected. None of it is interoperable. Anyone who wants to build a product on top of accessibility data has to build the dataset themselves, from scratch, for every city. So they don't.

What a "GTFS for accessibility" actually looks like

The lesson from GTFS is not "publish a CSV." It is:

  1. Agree on a vocabulary. Define the fields. Decide what a step-free entrance means, what an accessible restroom means, what counts as nonverbal ordering. If we cannot describe a concept with a known field, the field needs to be added.
  2. Make it machine-readable. No prose, no PDFs, no asterisks. The schema is the contract.
  3. Make it multi-source. Businesses, cities, audit organizations, community contributors, and verified observations should all be able to contribute. The format should not care who is publishing.
  4. Make it refreshable. A static spec is a static dataset. Accessibility data has to be refreshed continuously, with timestamps and provenance.
  5. Make it free to use. The whole point of an ecosystem is that anyone can build on top.

GTFS got these right. We can learn from that.

What changes when accessibility becomes legible

The most interesting thing about GTFS was not the spec. It was what people built on top of it. Trip planners, third-party navigation apps, accessibility-aware routing, paratransit integrations, on-time arrival predictions, fare comparison tools, and eventually transit-aware AI assistants.

The same expansion is possible for accessibility:

  • Mapping platforms that let people filter by their actual access needs, not a single checkbox.
  • AI assistants that can answer "find me a quiet café within ten minutes with a step-free entrance and nonverbal ordering" and mean it.
  • Tools for businesses to see how their space is described and update what has changed.
  • Tools for cities to understand accessibility coverage at a neighborhood level instead of one venue at a time.
  • Tools for community organizations to audit and contribute structured observations rather than write reports nobody reads.

None of these require new science. They require shared data.

We are at the moment

Three things make this the moment to build the accessibility standard:

  • AI has moved into the physical world. Assistants are making recommendations about real places, and they need real data to do it safely.
  • Distributed audit and observation are now operationally possible. Mobile devices, structured forms, and distributed workforces can collect the data at the scale a real standard requires.
  • The cost of waiting is rising. Every year without this layer is a year of decisions made on guesswork.

GTFS was not inevitable. It happened because a small group of people decided to write a spec and a few cities decided to use it. The accessibility version of that moment is now, and the spec is what we are building.

If you want the physical world to be legible to everyone (humans, cities, and the AI systems we are increasingly relying on), accessibility data has to become infrastructure. That is the work.