The MBTA recently updated how it calculates platform accessibility, a performance metric in its Service Delivery Policy (SDP) which measures how often MBTA platforms are actually accessible to riders who rely on elevators. In this post, we show how new data sources available to the public enable amore standardized and streamlined calculation of platform accessibility, while also raising important questions about how accessibility is defined.

‍

Introduction: Accessibility in the Service Delivery Policy

The MBTA’s Service Delivery Policy (SDP) sets the framework for evaluating the quality of transit service across the Massachusetts Bay region by defining a set of service objectives – one of which is accessibility. Each objective is measured by one or more standards (performance metrics) which the MBTA monitors regularly and reports publicly each year to gauge how well service meets its standards. Following the adoption of an updated 2024 SDP last December, which revised several existing standards and introduced new ones (see this blog post for a deeper dive), the Fall 2024 SDP Annual Report, published on June 4, 2025, is the first to evaluate performance under the new policy, including several new and updated accessibility standards.

To measure the service objective of accessibility, the SDP considers not just the presence of accessible design features in transit vehicles and stations (e.g., using metrics like Station Accessibility) but also the ongoing usability of these features, particularly the operation of elevators. The Platform Accessibility metric underwent a major update in 2024to more accurately reflect the rider experience by revising both the calculation methods and policy standards applied.  In this post, we’ll take a closer look at the background behind Elevator Uptime and Platform Accessibility, explaining how recent changes to our data sources and methodology help us better measure and report on platform accessibility systemwide.

‍

Elevator Uptime

Measuring the operational uptime of elevators is an important component of accessibility performance reporting because it shows not just whether elevators exist in MBTA stations, but how well they are maintained in working order. This measure is especially important in the context of the amended Daniels-Finegold Settlement Agreement, signed in 2018, which has guided many of the accessibility improvements made to the system over the years. Among its provisions, the settlement includes a specific requirement for elevator uptime: the MBTA must keep uptime above 99.40% for any consecutive 3-month period.

While the SDP Elevator Uptime metric echoes the settlement’s language and goals to convey a general sense of how the agency is performing in this area, the SDP metric measures elevator uptime across the entire Fall rating period, rather than on a monthly basis, and is not intended as a direct benchmark for compliance. Notably, both the Elevator Uptime and Platform Accessibility metrics in the SDP only consider elevators that are maintained by the MBTA. Some stations have elevators that are maintained by non-MBTA entities, such as municipalities, and those elevators are excluded from both SDP metrics.

While the Elevator Uptime metric is important for monitoring elevator reliability , it does not reflect the variety of impacts to riders. One way the MBTA’s performance monitoring captures some of these impacts is through the Platform Accessibility metric.

‍

Platform Accessibility

Background

Elevator outages due to maintenance or equipment failure have less of an impact when there is redundancy through other working elevators or other accessible means by which riders can reach a given platform.¹ Conversely, it is also possible for a single elevator outage to impact access to multiple platforms. The Platform Accessibility metric is designed to take these factors into account, measuring the percentage of total “platform-hours” that are ADA-accessible at platforms for which access is enabled by MBTA-maintained elevators. Platform-hours for a given station are calculated by multiplying the number of elevator-dependent platforms by the total number of hours when service is offered at each platform.

Importantly, since this is specifically a metric focused on elevator access to platforms, a given platform(boarding location) is only included in this metric if access to and from the platform depends on the functioning of elevators. This excludes platforms that are intrinsically accessible (e.g., a platform directly connected to the street via flat surfaces & ramps, such as a South Station commuter rail platform) and platforms that are intrinsically inaccessible (e.g., an underground platform only reachable via stairs/escalators, with no elevators present, such as the platforms at Bowdoin station). The prevalence of these types of platforms in the MBTA system is captured by the Station Accessibility metric, and the accessibility of how vehicles interface with platforms is captured by the Station Accessibility and Vehicle Accessibility metrics.

¹This type of redundancy has been a focus of stakeholders arguing for improved accessibility at the MBTA. Notably, the original BCIL Settlement agrees to installing redundant elevators at 4 stations along the red line (including improved connections with the Green and Orange Lines).

‍

Recent Updates to Data and Methods

While the primary goal of the 2024 policy update was to clarify how temporary shuttling is counted in platform accessibility scores (bus shuttles to another station with a functioning elevator are no longer counted as periods with accessible platforms, as discussed in a previous blog post), the new policy also presented an opportunity for OPMI to overhaul the data sources for platform accessibility to make the calculation more accurate and robust.

Calculating platform accessibility requires data on (1) the days and times that each elevator is operational, (2) the days and times that service is offered at each platform, and (3) platform dependencies (which platforms are dependent on elevators, and which elevators going offline would render a given platform inaccessible). For the Fall 2024 SDP report, OPMI transitioned to new data sources for all three of these components of the calculation, pulling from several recently developed and publicly available General Transit Feed Specification (GTFS) and elevator alerts datasets that are maintained by the MBTA’s Lightweight Application for Measuring Performance (LAMP) program. By calculating the Platform Accessibility metric using these data from the MBTA’s passenger information systems, OPMI retired several time-consuming manual tracking processes while also improving metric accuracy.

Table 1: Summary of Updates to SDP Platform Accessibility Data Sources

‍

Our elevator alerts dataset saw only minor updates in 2024, with its core information (the start and end time for each recorded outage of a given elevator) remaining relatively unchanged. The more substantial changes in our methods are the calculations of service offered hours and platform dependencies, with the latter representing a particularly complex change built on a relatively new data source: GTFS pathways.

‍

Measuring Platform Dependencies using GTFS Pathways

Pathways are an optional component of the GTFS schedule standard which encode station information to enhance passenger navigation. Routing applications can use GTFS pathways data to provide riders with step-by-step instructions on how to reach a given boarding location from the entrance of a station or vice versa, optionally filtering to avoid stairs or escalators based on passenger needs. However, GTFS pathways also provide a convenient format of data for measuring platform accessibility.

In a GTFS pathways file, each row represents a path between two locations inside a station. Each pathway is described (at a minimum) by its mode (e.g., walkway, stairs, elevator) and its directionality (either one-way or two-way).  Station locations are represented in the GTFS stops file, and are categorized by “location types,” such as boarding locations (platforms),entrances/exits, or generic locations within stations (e.g., the top or bottom of an elevator). Taken together, stops and pathways in a GTFS feed represent pedestrian travel within station using a network graph format built on nodes (stops) and edges (pathways), as depicted in Figure 1.

‍

‍

The MBTA’s implementation of GTFS also associates certain pathways with “facilities,” an extension of the GTFS standard which identifies specific elevators, escalators, and other station amenities. For example, the ability to travel from the bottom to the top of an elevator would be represented as a pathway associated with the facility ID of that elevator. By combining these GTFS data with information about when a given facility was out of service (e.g., MBTA elevator alerts), we can determine whether a given pathway was actually available to riders at a given time. OPMI’s R-based implementation ofthis function is displayed in the code block below.

# find the immediate reachable neighbors of a given stop ID given a set of usable modes & out-of-service elevators
getNeighbors <- function(stopId, stop_type=match.arg(c("from_stop_id", "to_stop_id")), 
                         stationPathways, oosElevatorIds, usable_pathway_modes) {
  # if the provided stopId is a to_stop_id, get its from_stop_id neighbors, and vice versa
  neighbor_stop_type <- setdiff(c("from_stop_id", "to_stop_id"), stop_type)
  
  stationPathways[
    stationPathways[[stop_type]] == stopId # Find pathways that either start or end at the provided stopId...
    & stationPathways$pathway_mode %in% usable_pathway_modes # ...that are usable with the specified modes...
    & !(stationPathways$facility_id %in% oosElevatorIds) # ...and that do not use out-of-service elevators...
    , neighbor_stop_type] # ...and return the stop IDs with which the provided stopId is connected via those pathways
}

# find all reachable stops relative to a given stop ID, given a set of usable modes & out-of-service elevators
getReachableStopIds <- function(platformId, stop_type=match.arg(c("from_stop_id", "to_stop_id")),
                             oosElevatorIds, usable_pathway_modes, stationPathways) {
  reachableStopIds <- c() # initialize a set of stop IDS that are reachable relative to platformID
  q <- c(platformId) # initialize a queue of stop IDs to check
  
  while (length(q) > 0) {
    # access and remove the first stop from the queue
    curr <- q[1] 
    q <- q[-1]
    
    if (!(curr %in% reachableStopIds)) { # if we have not already identified the stop as reachable...
      # ...get its neighbors in the pathway direction specified by stop_type...
      neighbors <- getNeighbors(curr, stop_type, stationPathways, oosElevatorIds, usable_pathway_modes)
      q <- c(q, neighbors) # ...add them to the end of the list of stops to check (first in, first out)...
      reachableStopIds <- c(reachableStopIds, curr) # ...and mark the stop as reachable 
    }
  }

  return(reachableStopIds)
}

‍

To translate pathway availability into platform accessibility, our calculation includes a function which implements the breadth-first search algorithm to calculate the set of station locations that a rider could reach at a given time from a given place in the station, given the station’s pathways, the set of pathway modes that are available to the rider, and the set of elevators that are in service at a given time. A platform is considered dependent on elevators if (1) it is possible to board, exit, and make any transfers within fare control that may be applicable using elevator pathways, and (2) at least one of these three movements is not possible in the absence of elevator pathways. Similarly, a platform is considered inaccessible at a given time if a set of elevator outages at that time makes it impossible for riders to board, exit, or make transfers using only accessible pathway modes.

However, most stations have multiple entrances and exits, raising questions about the conditions under which a platform is considered accessible. Should a platform be considered accessible if it is reachable from any entrance, or must it be reachable from all entrances? Is there some in-between option that should be used? In reality, the answer to these questions varies by station, depending on the locations of other entrances and the accessibility of the surrounding streets, information which is absent from GTFS pathways data.

Only requiring one entrance to be usable could misrepresent accessibility at stations where there is a large distance or significant elevation change between entrances. For example, if the elevator at the Forsyth Street entrance at the Ruggles station goes out of order, some riders would have to travel more than a quarter of a mile through a college campus, out of sight of the station, making two turns to an uphill stretch of road and alongside a busway to reach an accessible entrance.

One “in-between” standard OPMI considered is to require that at least one entrance be usable for each "level" of the station. This appeared to be a fair compromise made possible by the fact that the relative vertical positions of station locations are represented in the GTFS levels file that is used in conjunction with pathways. However, this standard does not work for stations like Airport where tracks are at same level as the entrances, making elevators necessary to reach the opposite platform from a given entrance. For some elevator outages, it would be possible to maintain access at each level of Airport station, but the true accessible path to the other platform would require traveling half a mile outside the station, leaving sight of the station, under a 6-lane set of highway ramps, and on an overpass over an additional 2 highway lanes.

‍

‍

Ultimately, defining a platform accessibility standard requires making judgment calls about which potential alternative pathways, whether inside or outside a station, are both sufficiently accessible and comparable to what the journey would have been with a working elevator. GTFS pathways data offer some options for making these determinations programmatically, but the any-entrance, all-entrances, or all-levels standards may not be adequate proxies for accessibility in all station contexts since paths around stations are not part of the scope of GTFS pathways data.

To err on the side of caution, our default requirement is that a given platform be reachable from all elevator-dependent entrances at all times. However, we calibrate these determinations of platform accessibility with the professional judgment of the MBTA’s Department of System-Wide Accessibility (SWA). Their determinations about the presence of a viable alternative path for elevator outages across the MBTA system are contained in the MBTA’s elevator alert messages to passengers.

Specifically, if our GTFS-pathways-based calculation identifies a platform as inaccessible from at least one entrance at a given time, but the corresponding alert message implies that a viable alternative at the same station existed (e.g., using another entrance or another elevator), we count that platform as accessible at that time. Alert messages which instruct passengers to use a temporary shuttle or to add an extra leg on their journey (e.g., by continuing on their train or bus to another station and then turning around to use working elevators on the other side of a station) are assumed to represent times when no accessible alternative pathways were available at the station. To distinguish between these kinds of scenarios programmatically, we employ a set of keyword detection criteria that were developed based on a comprehensive review of elevator alert messages.

While we judged that GTFS pathways data were not sufficient on their own for making 100% accurate platform accessibility determinations in the MBTA context, they represent a valuable standardized data source for both intra-station passenger navigation and accessibility performance measurement. They also enabled OPMI to design a conservative algorithm that can update over time as station entrances and pathways change, with appropriate scaffolding to include standardized and traceable expert opinion.

‍

Measuring Service Offered Hours using GTFS Schedules

Another critical component of the platform accessibility calculation is to define the denominator of platform hours: the total time when service is offered on each platform, summed up overall platforms. We refer to this time on a given platform as “service offered hours” to distinguish it from “service hours,” which usually refer to the total time spent by transit vehicles operating on a given route.  

The previous process for calculating platform accessibility assumed that all platforms had service running from 5:00am to 1:00am for a daily total of 20 service offered hours. The process also relied on OPMI analysts to manually encode any exceptions to this assumption, such as a pre-planned service diversion resulting in fewer-than-normal or no service offered hours on a given day. To more accurately count how many hours of service were actually offered on each platform on a given day, the new platform accessibility calculation pulls from the MBTA’s GTFS schedules.

The GTFS schedule standard was designed to encode transit service in a format that allows routing applications to provide riders with trip recommendations based on the services that are scheduled to operate at a given place and time. However, GTFS schedules also provide a convenient format of data for counting service offered hours and other scheduled service statistics for performance metrics like platform accessibility.

GTFS feeds consist of a series of files that define the services that are scheduled to operate on a given day, the trips that belong to a given service, and the times when those trips are scheduled to arrive at and depart from individual stops. On a given service day, the service offered hours at a stop are calculated as the time elapsed from the first trip departure to the last trip arrival at that stop. Any planned service diversions that reduce or eliminate the duration of a given service day at a given stop are reflected in the GTFS calendar and calendar dates files, which define which services were scheduled to operate on a given day.

To calculate service offered hours for the entire Fall 2024 season without having to download individual feeds from the MBTA’s GTFS archive, we used the compressed GTFS archive published by the MBTA’s LAMP program. These files are structured in the same way as individual GTFS feeds but have two additional fields (gtfs_active_date and gtfs_end_date) which indicate which records were applicable on a given service date. This feature of the MBTA’s compressed GTFS archive makes it possible to calculate service offered hours and other scheduled service statistics over a long date range without having to iterate over many individual GTFS feeds.

‍

‍

Figure 3 shows that including more accurate calculations of service offered hours based on GTFS schedules makes a small but non-trivial difference on platform accessibility results. The fact that service diversions are embedded in GTFS feeds rather than being manually recorded by OPMI as part of the platform accessibility calculation helps ensure that any inaccuracies in recording service offered hours do not unduly penalize elevator outages that occurred when service was not offered and thus had no rider impact. Calculating service offered hours for each stop based on scheduled stop times instead of assuming a 5:00am to 1:00am service day also ensures that the metric does not provide undue credit for elevators functioning properly during times when service was not offered.

Our transition between data sources also led us to confront how to count the number of platforms in the system, and thus how platforms are defined in the first place. In the GTFS stops file, a “platform” refers to a unique location where riders board or alight from a transit vehicle within a “parent station.” However, this is a loose definition that leaves room for different interpretations by individual transit agencies that produce GTFS feeds, meaning that counting platforms is not necessarily as simple as counting unique GTFS stop IDs.

For example, the GTFS standard does not provide guidance about whether island platforms (where trains run on each side of the platform) should be represented using one stop ID or multiple stop IDs. Even within the MBTA’s implementation of GTFS, island platforms are not treated in a uniform way. One stop ID is used for the island platform at Alewife and for those at several other line termini, whereas two stop IDs are used for the island platform at Davis and for those at many other non-terminus stations. Meanwhile, Park Street’s eastbound platform has four separate stop IDs corresponding with the different berths associated with each branch of the Green Line.

For the purposes of calculating platform accessibility, OPMI currently treats each GTFS stop ID as a separate platform but double counts the service offered hours for a subset of bidirectional stop IDs to ensure that functionally similar platforms are treated consistently. We define a bidirectional stop ID as a stop where close to 50% of the trips serving that stop ID operate in each direction. Counting each stop ID as a platform without this additional treatment would result in(for example) platform hours at Alewife counting half as much as platform hours at Davis. Defining bidirectional stops in this way also avoids inflating the importance of platforms where only a few trips operate in the non-predominant direction(a common pattern on some Commuter Rail platforms).

Ultimately, the sensitivity of the platform accessibility metric to inconsistencies in how platforms are defined can point toward ways in which the metric could be extended or modified in the future to better capture rider experience or agency priorities. To the degree that access to platforms with very little service might be arguably less important to prioritize than access to platforms with a large amount of service, it could be valuable to measure platform accessibility as a percentage of scheduled trips during which accessible pathways were available on elevator-dependent platforms, rather than a percentage of platform hours. Alternatively, to prioritize platform access at high-ridership platforms and times of day, a ridership-weighted platform accessibility metric could be constructed by weighting service offered hours and elevator operating hours by average ridership levels per platform and time period.

‍

Conclusion

While exploring new units of analysis for platform accessibility (e.g., trips, riders) could help sidestep some of the idiosyncrasies in how platforms are defined in GTFS or similar data sources, the “unweighted” platform accessibility metric currently used in the SDP remains a valuable indicator of how well the MBTA delivers accessible service to riders who rely on elevators. OPMI’s use of GTFS pathways and elevator alert messages to determine platform access and of GTFS stop times to calculate service offered hours embody a shift toward more accurate and standardized calculation methods using publicly available data.  OPMI can be reached at opmi@mbta.com for questions, comments, or feedback about performance reporting and open data at the MBTA.

‍

‍

‍

‍