June 22, 2026 · 7 min read · Industry

Accessibility data is the gap in travel APIs.

Wheelchair access at a museum entrance. Sensory-friendly hours at a landmark. Audio-described guides. Step-free station entries. Most travel APIs return none of this. The honest reason is that the data isn't well-collected anywhere — including in our own system. This is an industry gap, and pretending otherwise harms the users who need it most.

What's actually available

OpenStreetMap carries a wheelchair tag with values yes / limited / no / designated. Coverage is highly uneven: dense in central London, Berlin, Amsterdam, and Tokyo; sparser in Bangkok, Mexico City, and Cairo; very sparse in most smaller cities everywhere. The tag is contributor-driven, so quality correlates with how active the local OSM community is, not with the actual accessibility of the venue.

Wikidata carries P2846 wheelchair_accessibility on a fraction of notable places, with values yes / no / partial. Coverage is even sparser — it's a relatively new property and only the most- edited entries have it.

OSM also carries tactile_paving, wheelchair:description, blind=yes, and a handful of related tags, with even sparser coverage. Few municipal open-data programmes publish accessibility audits in machine-readable form. New York's MTA station accessibility data is unusually good. Transport for London publishes step-free station data. Tokyo's metro publishes elevator data. Most cities don't.

What we return today

The /v1/places response surfaces the OSM wheelchair value where present. We pass it through unchanged. We don't interpolate, we don't infer from venue category, we don't fall back to "probably yes" — because for the user who needs the answer, a confident wrong answer is worse than no answer.

GET /v1/places?city=london&type=museum
{
  "name": "British Museum",
  "wikidata_id": "Q6373",
  "lat": 51.5194,
  "lon": -0.1270,
  "accessibility": {
    "wheelchair": "yes",
    "source": "osm",
    "last_verified": "2025-11-12"
  }
}

# Compare:
{
  "name": "Some smaller venue in Cairo",
  "accessibility": null
}

A null is informative. It says: we don't have data, the venue may or may not be accessible, contact them directly. A user planning around accessibility constraints needs that signal honestly.

What good coverage would look like

Per venue: entrance step-free or not, with a measurement (number of steps, height in cm if any). Accessible toilet on premises. Lift to upper floors. Width of the narrowest aisle in cm. Audio-described or signed tours, with schedule. Sensory-friendly hours. Service- animal policy. Hearing-loop installations.

Per transit station: step-free entry, lift to platform, accessible toilet, tactile paving on platform edges, audible station announcements. The London Tube and the New York Subway publish machine-readable versions of most of this; Berlin U-Bahn does some; Paris Métro is famously poor on lift coverage and the open-data reflects that honestly.

Per city: a transit-system summary score, a tourism-attraction summary, and a flag for cities where the topology itself (cobblestones in Lisbon's Alfama, the steep streets of Cape Town's Bo-Kaap, the stair-climbs of central Naples) makes broad mobility difficult independent of any one venue's accessibility.

Why nobody has shipped this end-to-end

Three reasons. First: the data collection is high-touch. Audits require physically measuring entrances, which doesn't scale through a scraper. Second: the standards are fragmented. There is no single universal schema for "is this venue accessible." Third: the audience is comparatively small per venue, so the commercial case for an aggregator to fund collection has been weak. Several municipal and nonprofit projects have tried — Wheelmap.org, AccessNow, AXS Map — with partial success.

Our position

We pass through what OSM and Wikidata have. We add structured nullness when they don't. We do not invent accessibility metadata from venue category. We watch the public-sector open-data programmes in major cities and integrate them as they become available. Where a customer needs higher-quality coverage in a specific city, we'll work with them on a sourcing project — that's a service contract, not an API claim.

The honest summary: this is the largest gap in our coverage, and in the industry's coverage, and we don't want to paper over it. The users who depend on accessibility data are best served by APIs that say "we don't know" when we don't.