Wheelchair-Accessible Public Transport Routing Is Now in BusMaps

Product and API update - 27 July 2026

The fastest public transport route is not useful when a passenger cannot enter a station or board the scheduled vehicle. BusMaps can now use the accessibility data published in GTFS to filter route searches, show accessible stops and trips, and expose the same information through the BusMaps Public Transit API.

We built this after seeing a repeated need from people using trip planners and from teams integrating public transport data. A journey planner may know that a train leaves in eight minutes, yet still fail to answer the first practical question for a wheelchair user: can I make this trip? The answer depends on two separate facts. The stop must provide an accessible boarding path, and the vehicle assigned to the trip must be able to carry a wheelchair.

A new option in the BusMaps Trip Planner

The BusMaps Trip Planner now includes Wheelchair accessible under Route options. It is a route choice alongside Best route and Fewer transfers. Selecting it runs the public transport search with the strict accessibility mode: both the boarding stops and the scheduled trips must be marked accessible.

The example below travels from London Paddington to Farringdon on the Elizabeth line. In the routing response, London Paddington and Farringdon both have wheelchairBoarding: 1, and the selected Elizabeth line trip has wheelchairAccessible: 1. The itinerary takes 10 minutes and includes 125 m of walking in total.

This is a useful test case because the accessibility record is consistent with Transport for London guidance: all Elizabeth line stations are step-free from street to platform, while stations between Paddington and Woolwich are step-free from street to train. The Trip Planner marks the accessible boarding point in the detailed itinerary.

What changed in the BusMaps Public Transit API

The BusMaps Public Transit API used by the website and external integrations now supports accessible journey planning. Two methods accept barrierMode:

• GET /routes filters complete itineraries between an origin and a destination.
• GET /nextDepartures filters departures near a coordinate or at a specified stop.

The website uses mode 1 because it is the only value that checks both parts of the journey. Modes 2 and 3 are available to API clients that have another source for the missing half, or that need to inspect data coverage independently.

curl -H "capi-key: Bearer YOUR_API_KEY" \
  -H "capi-host: busmaps.com" \
  "https://capi.busmaps.com:8443/routes?origin=51.5154,-0.1755&destination=51.5202,-0.1053&barrierMode=1&lang=en"

Accessibility is also present in Public Transit API responses. Stop objects use wheelchairBoarding. Transit sections and scheduled trips use wheelchairAccessible. The /stopsInRadius, /trip, and /line responses expose these values so an application can show the information even when it is not running a filtered route search. In /line, each stop may contain wheelchairBoarding, while each compact schedule trip may contain wheelchairAccessible beside its trip ID and stop-time list.

{
  "departure": {
    "place": {
      "name": "London Paddington",
      "wheelchairBoarding": 1
    }
  },
  "transport": {
    "name": "Elizabeth line",
    "wheelchairAccessible": 1
  },
  "arrival": {
    "place": {
      "name": "Farringdon",
      "wheelchairBoarding": 1
    }
  }
}

Wheelchair-accessible routing for AI assistants

The same accessibility features are available through the BusMaps Transit MCP Server. Claude, ChatGPT, Gemini, Cursor, and other MCP clients can use plan_transit_route and get_departures with barrierMode. This gives an AI assistant a direct way to find accessible journeys and departures while preserving the stop and trip accessibility information returned by the Public Transit API.

Connect an MCP client to https://mcp.busmaps.com/mcp, then ask, for example:

• Plan a wheelchair-accessible public transport route from London Paddington to Farringdon.
• Show wheelchair-accessible departures near Manchester Piccadilly.

The server exposes 23 read-only transit tools with discoverable schemas. An assistant can therefore identify the available parameters and call the appropriate BusMaps tool without requiring the user to translate a journey question into an API request.

What the GTFS values mean

The fields come from the open GTFS Schedule specification. In stops.txt, wheelchair_boarding describes whether boarding is possible at a stop, platform, station, or entrance. In trips.txt, wheelchair_accessible describes whether the vehicle used for a particular scheduled trip can accommodate at least one rider in a wheelchair. The official GTFS accessibility guide stresses that both the stop and the trip must be accessible for a passenger to use the service.

Both fields use the same numeric convention: 1 means accessible, 2 means not accessible, and 0 or an empty field means no information. Unknown does not mean inaccessible. BusMaps keeps that distinction in the API and omits unknown accessibility fields from compact responses rather than presenting uncertainty as a negative result.

Accessibility coverage in the latest BusMaps data

The latest BusMaps accessibility analysis covers 4,000 of the 7,000+ feeds processed by BusMaps - 4.7 million unique boarding points and 29 million trip records. Accessibility information is considered known when a publisher explicitly marks a boarding point or trip as accessible or not accessible. Missing values remain unknown. All figures in this section are rounded.

Of the unique boarding points with a known value, 350,000 are marked accessible and 180,000 are marked not accessible. For trips, 6.4 million are marked accessible and 1 million are marked not accessible. These figures describe data publication, not the share of a country's physical network that is accessible.

Wheelchair accessibility data by region

North America has the most balanced regional coverage, with known values for 27% of boarding points and 43% of trips. Europe and Asia have broader trip coverage than boarding-point coverage. Oceania shows the largest gap: trip accessibility is available for 66% of records, while boarding information is available for only 3%. This makes stop-level publishing the main opportunity for improving accessible journey planning in the region.

Accessibility coverage by country

Wheelchair accessibility data coverage varies significantly between countries. The table combines countries with large published accessibility datasets and countries where boarding-point and trip coverage differ sharply. Countries are ordered by their lower coverage percentage, from highest to lowest, because reliable accessible journey planning depends on information about both the boarding point and the scheduled vehicle.

• France and Canada publish substantial coverage for both sides of an accessible journey: boarding points and scheduled trips.
• The Czech Republic, Finland, Australia, Poland, and Hungary have much stronger trip coverage than boarding-point coverage.
• The Netherlands, Indonesia, and Singapore show the opposite pattern: boarding information is much more complete than trip information.
• Thailand has high coverage for both fields, although its published dataset is smaller than the national datasets at the top of the table.
• Germany and the United Kingdom contain large transit datasets, but known boarding-point values remain below 1%.

GTFS feeds with complete wheelchair accessibility data

A quality-only comparison produces a large tie at the top: 230 feeds provide known accessibility values for 100% of both boarding points and trips. Another 50 feeds cover at least 90% of both fields. The table shows examples from the complete-coverage group. Feed size does not affect qualification. Counts are rounded, and each dataset name links to its current feed page.

Credit belongs to the publishers

A routing engine can only use accessibility facts that reach the feed. The strongest examples in this data come from agencies and data publishers that maintain both the stop and trip fields. Warsaw Public Transport, STM Montreal, TTC, CTA Chicago, STAR, TriMet, Metro Transit, and Miami-Dade Transit provide known values for every boarding point and trip record in their feeds. MiWay, Niagara Region Transit, RTL, York Region Transit, Grand River Transit, CDTA, and Bilbobus do the same.

We thank these operators and data publishers for treating accessibility information as part of the core passenger service. Their work allows journey planners, accessibility applications, and passengers to make decisions using explicit data instead of assumptions.

Publishing an explicit 2 is also useful. It prevents an application from offering a trip that the operator knows cannot accommodate a wheelchair. Leaving the field empty communicates a different fact: the publisher has not supplied an answer. Accurate negative values and accurate positive values are both better than silence.

GTFS can describe more than these two fields. Station entrances, parent stations, platforms, pathways.txt, and elevator levels can model how a passenger moves through a complex station. The current BusMaps filter uses the stop and trip accessibility values carried by the routing data. It does not certify every pavement, crossing, elevator, temporary closure, or platform gap on the journey. Passengers should still check live operator guidance where a lift outage or other disruption could change access at short notice.

For agencies and application developers

Agencies can improve accessible journey planning without creating a new proprietary format. Add and maintain wheelchair_boarding in stops.txt and wheelchair_accessible in trips.txt, use 0 only when the status is genuinely unknown, and republish the feed when vehicles or station access change. BusMaps will carry those fields through its feed pages, API responses, departure boards, route timetables, and filtered journey search.

Application developers can start with barrierMode=1 for strict filtering, then display the returned fields beside the relevant stop and transit leg. Read the complete Public Transit API documentation for authentication, time handling, response schemas, and tested request examples. To discuss data integration or a Public Transit API account, use the BusMaps contact form.