Investing in Accessibility & Technology Pays Off for MBTA Riders
Last month, Boston became one of just 6 cities in the world with Google Maps’ latest feature: wheelchair-accessible trip-planning.
We were thrilled to see this new feature made available to our customers, and even more so to see the MBTA featured in Google’s announcement. But as the saying goes, “simple is hard”: what looks like just another button in a Google Maps menu is actually the result of a tremendous amount of work — work that wouldn’t have happened if the MBTA hadn’t spent the last decade investing in accessibility and, more recently, in customer technology.
Our goal is to support independent trips. It’s almost like the ideal would be for us to not hear about this, for it to just be there in the app that people are already using. The access community always feel like they’re scrapping for attention, we’re always associated with being the hard-stop on projects. So it’s very, very exciting to see the energy around this project. The fact that Google put this out makes it cool, rather than some bureaucratic, government thing.
— Kathryn Quigley, Deputy Director of Strategic Planning for System-Wide Accessibility
Given the pride and excitement, we thought we’d share the story of how this new feature came to Boston. It’s a story of collaboration between 2 departments — one charged with ensuring that all MBTA services are accessible and inclusive for customers with disabilities, System-Wide Accessibility (SWA), and one charged with bringing novel ideas, modern standards, and a human-centered approach to our technology, Customer Technology (CTD).
Data collection is the hard part
Transit agencies are responsible for collecting data on the accessibility status of their networks. The MBTA has long had this information for subway and commuter rail stations, as well as ferry docks. And it has been available to customers on our website and Trip Planner, and made available to third party services in our General Transit Feed Specification (GTFS) feed as well as our API.
But we’ve never had this information for bus stops. Frankly, collecting it never seemed feasible. We have 7,685 bus stops along 734 miles of routes, spanning almost 3,000 square miles across more than 100 cities and towns in Greater Boston. And most of them are on property that the MBTA doesn’t own or maintain. It’s hard enough to keep track of how many bus stops there are, let alone how far each one is from a curb cut, how high the grade differential to the street is, and all of the other characteristics that affect accessibility.
In 2016, SWA launched their Plan for Accessible Transit Infrastructure (PATI). The goal was to develop a long-term capital funding plan to achieve a fully accessible transit system. And to get there, they needed to identify all meaningful barriers to access across the MBTA’s service area. As part of PATI, SWA developed a methodology and tablet-based survey to capture accessibility information about each bus stop. Over the course of 9 months, a survey crew of 20 spread out across the entire system to carry out this massive data collection effort.
At first, a bus stop seems so much simpler than a subway station that one would think identifying its “accessibility status” might be simpler, too. In trip-planning practice, though, the accessibility status of a subway station depends mostly on whether it has an elevator when needed. The accessibility status of a bus stop turns out to be much more complex: Does it have a level landing area? What material is it made of? Does it have a shelter? Is there an accessible route between the two? Is there something blocking the sidewalk? These aren’t easy questions to answer in the real world, especially when what constitutes a “bus stop” can vary a great deal.
By the summer of 2017, though, the data collection was complete and a new database had been populated.
A treasure trove of data
In October 2017, SWA sent us an export of their database — an Excel file with 7,685 rows and 888 columns that described each bus stop in rich, technical detail. Amazing as it was, it wasn’t immediately clear what we could do with this information. After spending some time with the “treasure trove of data,” as he called it, Josh Fabian, a transportation engineer on our Real-time Applications Team, had an idea.
He looked up the Americans with Disabilities Act’s (ADA) standards for transit facilities to see if he could collapse the 888 variables into a simple “true” or “false”: wheelchair accessible or not. Doing so, he figured, would allow the data to be used by way-finding applications. He pitched the idea to SWA, suggesting that this could alert customers to their destination stations’ accessibility status before they’d started their trip.
We went back and forth with Josh. We wanted to make sure that we were giving customers information without eliminating stops that they could reasonably use from their options. In reality, a bus driver will drop you off 10 feet away from the bus stop if there’s some sort of obstruction. So we worked with [Customer Technology] to shoehorn in our own definition.
— Laura Brelsford, Assistant General Manager for System-Wide Accessibility
Together, Josh and SWA came up with an “algorithm.” They quickly decided on a few features that would automatically disqualify a bus stop from being considered wheelchair accessible — a bench or trash can obstructing the only path to or from the bus stop, for example. Beyond that, the size of the “boarding and alighting area” (also called a “landing pad”; see diagram above) would be the critical variable. But using the ADA requirement of 8 feet by 5 feet — or 40 square feet — resulted in only 38% of bus stops being deemed accessible (see chart below). Eliminating almost two-thirds of our bus stops would result in people not taking trips that they really probably could. They felt that was too high a price to pay.
So the question was, where to draw the line?
In the end, Josh and SWA came up with a compromise. Whereas the “wheelchair_boarding” variable in GTFS asks for:
- 0, if there isn’t enough information
- 1, if the stop allows for wheelchair boarding
- 2, if the stop does NOT allow for wheelchair boarding
…we’re using:
- 0, for “Minor to moderate accessibility barriers exist at [stop_name]. Bus operator may need to relocate bus for safe boarding and exiting.”
- 1, for “[stop name] is accessible. It has the following features: [pulls from database].”
- 2, for “Significant accessibility barriers exist at [stop_name]. Customers using wheeled mobility devices may need to board at street level. Bus operator will need to relocate bus for safe boarding and exiting.”
That way, queries that eliminate only bus stops with “wheelchair_boarding = 2” won’t remove bus stops in the gray area of accessibility. In February, less than 6 months after we first saw SWA’s database, we added this information to our GTFS feed and our V3 API.
And then, one day in March, we woke up to the news that Google Maps now enables customers to plan wheelchair-accessible trips on our network.
Why we’re proud
Improvements to accessibility benefit all of our customers. It’s not just people with disabilities who use our accessibility services: It’s families with strollers, visitors with luggage, seniors, people who are transit-dependent for groceries, and more. But it’s how customers will experience this benefit that we think is particularly powerful.
In the architecture world, where I come from, people often talk about “accessible” doors. There’s an additional, button-operated door off to the side that’s for people with disabilities. Instead, you could just have a sliding door that everyone can use. That way, everyone’s having the same experience. That’s why [this Google Maps feature] feels so powerful: It’s right there, in the app that you’re already using. The inclusion is what’s so important. Universality and usability go hand-in-hand.
— Kathryn Quigley
This is a step towards making our transit system more equitable and more inclusive. And, for those of us who don’t work on accessibility every day, this project has been a reminder of the power of inclusive design.
What’s next
This is a big step towards SWA’s mission of supporting independent trips, but there’s a lot more to do to make truly accessible way-finding a reality. Here are the accessibility-related updates to the GTFS standard that are currently being discussed and evaluated:
- Real-time accessibility updates would allow us, for example, to update a station’s accessibility status right away in the event of an elevator outage. We currently notify customers of outages through a variety of digital channels, including our T-Alerts notification system, but leave it to them to figure out if and how those outages might affect their trips.
- If you want directions to the nearest subway or commuter rail station, your way-finding application will currently direct you to a point in space that represents the whole station! Entrance-specific accessibility statuses might be the solution to that problem.
- Finally, there’s a proposed change to account for each station as a network of platforms, paths, and entrances. This would allow customers to plan accessible trips without encountering barriers or dead ends.
Each of these will be projects unto themselves, requiring new data collection, new processes, and some learning and experimentation along the way. But we in Customer Technology are committed to enhancing our customers’ digital interactions with the MBTA — whether they’re interacting directly with MBTA.com or through services like Google Maps. And we’ll continue to partner with teams inside and outside of the MBTA to make those interactions as helpful, usable, and universal as we can.
