1 / Public Transport Service Model Projects
> Consider all the riders and their requirements when designing the service.
When beginning a new on-demand service (see details on such services here), or scaling it up, it is important to consider all the riders who might use the service and how their requirements might vary. While there are often legal requirements for accessibility features on vehicles and at pick-up/drop-off locations, much of the service design is left to the discretion of the public transport authority. When establishing the service area, for example, it is important to consider all the destinations that may be key community gathering places for certain groups such as senior centers. When considering the ways riders will interact with the service, it is important to take into account what is comfortable for everyone. It could be that a calling option is preferred in addition to an app. Special attention should be paid to languages to ensure everyone can interact with the service effectively. A holistic review of the draft design can ensure accessibility perspectives are integrated.
> Explore the Project: Roadmap for Expanding “Uber-like” Accessible Public Transport Service
> Explore the Project: Roadmap for Expanding “Uber-like” Accessible Public Transport Service
> Incorporate on-demand & demand-responsE services into regional mobility systems both on-the-ground and digitally.
When professionals decide to ensure that on-demand & demand-response transport services (ODT/DRT) are integrated into a regional mobility system that operates in urban, suburban, and rural contexts (see details on such services here), this can have a number of implications from an accessibility perspective. First, the effort itself could directly benefit people who simply prefer a “door-to-door” trip (similar to Uber’s service) instead of multiple “fixed route” public transport trips. People using mobility devices, for instance, may find it more convenient to deal with one vehicle instead of two for certain trips. Digitally, it is important that ODT/DRT services are put on equal footing with other public transport options. It is common not to show such services in trip planners and apps due to them having different data structures, such as a polygon for a service area as opposed to a line for a route. Not showing these services in trip planners and apps not only prevents people from using them in general, it also prevents using them to connect with other mobility services – hindering the mobility system functionality overall and for everyone. On the ground, it is important that ODT/DRT services are designed to connect with other aspects of the mobility system. Since ODT/DRT services are “flexible,” they often have no stops or stations. It can be beneficial from system connectivity and user comfort standpoints to connect the service area to commonly-used stations and stops – linking ODT/DRT directly with fixed route public transport.
> Explore the Project: Roadmap for Integrating “Uber-like” and Other Accessible Public Transport Services
> Explore the Project: Roadmap for Integrating “Uber-like” and Other Accessible Public Transport Services
> Take into account the needs of all riders when evaluating software features and functions.
When evaluating software options that support ODT/DRT services (see details on such services here), it is important to think about specific features and functions of the software that may be needed by users with particular requirements. With ODT/DRT services, trips must be booked and there is often the opportunity to provide additional information to the public transport authority to help them prepare. If a rider will have a service animal, for example, it is helpful to be able to add that “passenger” to the trip information within the same trip (with no extra charge). Another rider might have a health condition that requires them to travel with an aide, and that additional passenger should also be added to the booking (at no extra charge). A rider might use a mobility device; letting the driver know what type, size, etc. helps them prepare for space requirements and hands-on assistance. All of this helps ensure plenty of space in the vehicle and a more seamless trip booking experience.
> Explore the Project: Worksheet on Evaluating On-Demand & Demand-Responsive Software
> Explore the Project: Worksheet on Evaluating On-Demand & Demand-Responsive Software
2 / Technology & Data Maximization Projects
> Review accessibility data before making service and policy decisions.
Analyses that support accessible mobility can be included in projects that bring together various data points in order to generate new insights. For instance, a “service equity” analysis could be completed that combines various data points to understand if a proposed public transport service change would disproportionately impact people with certain characteristics such as lower income, older age, or disability.
> Explore the Project: Worksheet on Centralizing Data through Data Catalogues
> Explore the Project: Worksheet on Centralizing Data through Data Catalogues
> Share accessibility data with the public to improve the mobility experience.
The usage of data types that many agencies already have, such as GTFS-realtime, can be directed toward barrier-free purposes. For example, GTFS-realtime includes data on service interruptions such as elevator and escalator closures, which can be invaluable information for people using mobility devices on public transport systems. By ensuring that such data are included in GTFS-realtime data sets and are displayed in trip planning apps (Google Maps, Transit app, custom agency apps, etc.), accessible digital information objectives can be met.
> Explore the Project: Worksheet on Increasing Usage of GTFS-Realtime Data
> Explore the Project: Worksheet on Increasing Usage of GTFS-Realtime Data
> Adopt policies that further accessible mobility, such as “fare capping.”
When fare payment policies are reconsidered due to new software capabilities, accessibility policies can be adopted. For instance, the policy of “fare capping” could be established in digital fare payment and accounting systems that would prevent people (those with lower incomes in particular) from paying more for public transport service through a “pay as you go” system when compared to a “periodic” (monthly, annually) system. Since those with lower incomes may not have enough to pay in advance on a monthly or annual basis, they are often forced to take part in a “pay as you go” system. In short, once a rider has reached the fare cap for the month (set at the cost of the monthly pass, for example), they will not continue to be charged for any trips that month – even those purchased via the “pay as you go” system.
> Explore the Project: Fact Sheet on Reconsidering Fare Payment Policies Due to New Software Capabilities
> Explore the Project: Fact Sheet on Reconsidering Fare Payment Policies Due to New Software Capabilities
3 / New Concepts
> Leverage the Accessible version of concepts when possible.
Mobility as a Service (related to One-Call/One-Click Systems), a widely-known concept, has a lesser-known, accessibility-oriented version called Universal Mobility as a Service (MaaS). This concept was originally established by AARP in the US, building on examples present in Denmark. Whenever possible, it is best to lead with the accessibility-oriented version of any concept.
> Explore the Project: Training Event for One-Call/One-Click Systems (Part Two)
> Explore the Project: Training Event for One-Call/One-Click Systems (Part Two)
> Apply concepts that originate from an accessibility-oriented perspective.
The concept of “One-Call/One-Click” (OC/OC) systems was a precursor to MaaS in the US, but it originated from an accessibility perspective. OC/OC systems involve ensuring that everyone can get information and interact with all the mobility options in a system. From the National Center for Mobility Management’s (NCMM) Resource Center, the content of which was created by Civic Sphere, “OC/OC systems inform the public about most, if not all, available transportation options for all populations in a given geographic area. In their full deployment, OC/OC systems enable users to access trip information; where required, confirm eligibility for and book trips; and pay for trips. This allows community members to plan and implement travel within a single system or seamlessly across multiple systems.”
> Explore the Project: Resource Center for Learning About One-Call/One-Click Systems
> Explore the Project: Training Event for One-Call/One-Click Systems (Part One)
The “complete trip” concept, another example, “synthesizes aspects of a person’s trip from the time the individual begins to plan the trip, to when he or she leaves the originating location when starting a journey, to the doorstep of the final destination,” as defined in NCMM’s "Complete Trip" document. This approach encourages the professional to apply an accessibility framework to their work on the mobility system.
> Explore the Project: Guidebook on Digital Tools to Facilitate “Complete Trip” Planning
> Explore the Project: Resource Center for Learning About One-Call/One-Click Systems
> Explore the Project: Training Event for One-Call/One-Click Systems (Part One)
The “complete trip” concept, another example, “synthesizes aspects of a person’s trip from the time the individual begins to plan the trip, to when he or she leaves the originating location when starting a journey, to the doorstep of the final destination,” as defined in NCMM’s "Complete Trip" document. This approach encourages the professional to apply an accessibility framework to their work on the mobility system.
> Explore the Project: Guidebook on Digital Tools to Facilitate “Complete Trip” Planning