Accessibility for an automated passenger service

The passenger journey is the unit of design

A vehicle can have a step-free entrance and still deliver an inaccessible service. A passenger may be unable to use the booking app, find the pickup point, identify the arriving vehicle, ask for help when a journey changes or leave the vehicle safely after a breakdown. Removing a human driver makes these handoffs more important, not less. Accessibility evidence for an automated passenger service should follow the journey from deciding to travel through arrival at the destination and recovery from disruption.

Part 5 of the Automated Vehicles Act 2024 establishes the automated passenger service permit framework. Section 87 directs the appropriate national authority, when deciding whether to grant a permit, to consider whether and to what extent the permit is likely to improve understanding of how services should best be designed for and provided to older and disabled people. It also requires a permit condition concerning the holder's reporting on the service and steps taken to meet their needs and safeguard passengers. The exact permit terms and current guidance must be reviewed for each applicant.

The Department for Transport's pilot applicant guidance asks the applicant to show accessible booking, ways to interact with the operator, emergency procedures, entry and exit for people with mobility difficulties, and provision for passengers with assistance dogs. It also expects records of disability-related access problems and actions taken. This is a practical design and learning obligation, not a claim that a vehicle earns a universal accessibility certificate from one feature.

This page owns the end-to-end accessibility case for an APS applicant. The APS permit overview owns the general permit route. Local consent and traffic consultation are separate decisions. A future passenger emergency-support owner can examine incident response in greater detail. This page asks whether people with varied access needs can use the proposed service under ordinary and disrupted conditions, and whether the operator can prove it has learned from real users.

Start with people and tasks, not a feature list

Work with disabled and older people when defining what the service must do. Include people with mobility, sensory, cognitive and communication needs and people who use assistance dogs or travel with a companion. Avoid assuming that one participant represents everyone in a category. Ask how they plan a journey, pay, recognise the vehicle, board, secure equipment, request help, understand a diversion and leave at the destination. Include people who do not use a smartphone or who need an alternative to a visual display.

Map each stage: discovery, booking, pickup, identification, boarding, seating, journey information, help request, disruption, emergency, alighting, payment and complaint. For each, record the action expected of the passenger, the support available, likely barriers and evidence from testing. A service might be physically accessible on a level test surface but not at an uneven kerb. A booking form might pass an automated screen-reader check but still confuse a user when a pickup location changes. Human testing and operational observation are needed.

Do not frame accessibility only as equipment. The placement of a pickup point, its lighting and shelter, the crossing needed to reach it and the reliability of a support channel can determine whether the service is usable. A vehicle that cannot stop close to a safe kerb may need a different route or assistance arrangement. The operator should coordinate with the relevant traffic authority where road space or stopping arrangements need review. The service proposal should be precise about what it can and cannot support on day one, with a plan to address gaps.

The legal position may also involve equality and transport duties beyond the APS permit. This guide does not prescribe how those duties apply to a particular service or vehicle type. A transport and disability-access specialist should assess the exact facts, including applicable law, permit conditions and any conventional passenger-service rules that continue to apply.

Make booking usable through more than one channel

The DfT guidance expressly mentions accessibility of the booking platform. Test whether a passenger can find the service, identify an accessible vehicle, enter mobility or support needs, understand fare and cancellation terms, and receive a clear confirmation. Support assistive technology and plain language where appropriate. If the service is app-led, provide an alternative path for people unable to use the app. An advertised telephone number is not a real alternative if it is unstaffed when vehicles are running.

Consider what the operator needs to know and what it should avoid collecting. A passenger may need a ramp, space for a mobility aid, an accessible pickup point or a way to receive instructions by audio. The system should translate the request into a service action without asking for excessive medical detail. A data-protection specialist should review what personal data are collected, who can see them, how long they are kept and how a passenger corrects an error. Accessibility does not justify unrestricted sharing of sensitive information across vehicle and support suppliers.

Test failures. What if a passenger's phone dies after booking? Can they identify the correct vehicle and get assistance? What if an accessible vehicle is unavailable, a pickup point is moved or a payment fails? The service should explain alternatives without leaving the passenger to solve an inaccessible interface alone. Record how often a passenger could not complete a booking or abandoned it, because a service that measures only completed rides may hide the people it excluded.

A booking design should not promise assistance that operations cannot deliver. If the interface offers an in-person helper on request, the provider needs staffing, response limits and a way to confirm that help has actually been arranged. If a vehicle has a physical capacity limit, state it accurately and show an alternative where one exists. The aim is not to turn every limitation into a disclaimer. It is to prevent the service from accepting a journey it cannot safely provide.

Make boarding and alighting work at real stops

Accessible boarding is a combination of vehicle, kerb, route, time and staff support. Assess the actual pickup and drop-off locations with representative passengers and mobility equipment. Look at gradients, pavement width, tactile cues, obstructions, weather, lighting and traffic. If a ramp is fitted, test deployment when another vehicle is parked nearby or when the kerb is lower than expected. If passengers need help to secure a wheelchair or other device, define who provides it when there is no driver.

The service should tell a passenger which vehicle has arrived and where its accessible entrance is. Visual, audio and digital information may each fail for some users. Provide a reliable way to confirm identity before boarding. A passenger should not have to step into the road to read a vehicle number or see a screen. Test doors, handholds, seating, restraint instructions and the time allowed to board. The vehicle's automated departure logic should not begin moving because a sensor concluded that the door closed while someone is still securing equipment.

Alighting can be harder than boarding. The system should stop at a usable location, explain any deviation and allow enough time to leave. If the intended stop is blocked, the vehicle should not substitute a location that leaves a passenger across an inaccessible crossing or far from their destination without a support plan. The operator should know how to arrange a safe alternative and who pays or authorises it. A route-planning algorithm cannot substitute for a real assessment of the final metres of a journey.

Assistance dogs need deliberate provision. The DfT guidance includes them in the accessibility evidence expected from applicants. Test the vehicle space, boarding process, passenger information and incident procedure. Train support staff so they do not reject a valid journey because the system treats the dog as an unexpected object or because a generic animal rule was copied from another service. A specialist should check applicable legal duties rather than using this article as an eligibility test.

Give passengers a usable way to ask for help

Without a driver, the passenger's path to a person must be designed. The DfT guidance asks how passengers can interact with the operator, including through an app, service adviser, messaging or other means. Provide a route that works when a phone is lost, a passenger has a speech or hearing impairment, or connectivity is poor. A help button should communicate what happens after it is pressed and whether anyone has received the request. A screen saying help requested is insufficient if the support centre has no staffed response.

Separate journey assistance from automated-driving-system assistance. A remote worker may help a passenger understand a stop or arrange recovery without controlling how the vehicle drives. The operator should explain which team handles each request and how safety-critical issues are escalated. A passenger who reports a fire or medical emergency needs a different response from someone asking where to get off. Both require accessible communication, but the response pathway and urgency differ.

Provide clear journey information in a form passengers can perceive and understand. Tell them the destination, next stop, reason for delay and any change to pickup or drop-off. Do not rely on a tiny screen, audio alone or a push notification that may never arrive. Test how information works for people using hearing aids, screen readers or limited English. The applicant should avoid a claim of universal accessibility based on a single successful demo.

Support staff should understand the service's limitations and know how to arrange help without making assumptions about a passenger's disability. Give them authority to suspend a journey or request in-person assistance when a planned support method fails. Training needs practice with real scenarios, not just a script. Keep feedback from passengers confidential and use it to improve the journey.

Plan for disruption and evacuation

The DfT pilot guidance asks for emergency procedures and for an explanation of how passengers with mobility difficulties enter or leave the vehicle during incidents or service disruption. Start with realistic events: the vehicle stops in traffic, its doors cannot open normally, a lift fails, a passenger is unwell, a wheelchair restraint jams, power is lost or the support link fails. For each, determine what the vehicle does, who notices, what the passenger hears or sees, who can reach the site and how emergency services obtain access.

An emergency instruction must be usable by a person who cannot see a screen or hear a speaker. Test both channels and any alternative. A passenger with limited mobility may not be able to leave a stopped vehicle without assistance; telling everyone to exit immediately may be unsafe. The operator should have a plan for an accessible replacement vehicle or other suitable help. The precise response depends on the vehicle, road and passenger, and should be reviewed by safety and accessibility specialists.

Do not rely solely on an automated help system during a failure caused by a cyber incident or power outage. There should be a fallback way to contact and locate the vehicle. Staff should know how to give emergency responders vehicle-specific information, including how to immobilise it and reach passengers. The official first-responder guidance can inform those arrangements. The emergency-support owner in the AV map should cover the detailed response plan; this page ensures accessibility is built into it.

Practise with participants who use mobility aids or need alternative communications, with appropriate consent and safeguards. A tabletop exercise can identify responsibilities, but an on-site exercise reveals whether a ramp, door, support channel or recovery vehicle works. Record shortcomings and retest after correction. Do not claim that a plan is accessible simply because it contains the word evacuation.

Learn from complaints and failed journeys

The DfT pilot guidance says the applicant should record and investigate instances where a disabled person raises an issue about using the service and what action was taken. Build a process that makes reporting easy during and after a journey. Allow a passenger to report a barrier without needing to know whether it is a vehicle fault, booking defect or staff problem. Record the journey stage, barrier, impact, immediate support, investigation and corrective action. Protect personal information and avoid retaining more disability detail than needed.

Look beyond formal complaints. A high number of abandoned accessible bookings, repeated requests for the same pickup-point change, assistance calls at one stop or a low completion rate for wheelchair users can reveal a problem even where no complaint is submitted. The operator should ask whether the data measure who attempted to travel as well as who completed a ride. A dashboard limited to successful trips can create a false picture of inclusion.

The reporting condition under section 87 is intended to support learning about provision for older and disabled people and safeguarding. The permit holder should read its actual condition, current government guidance and any publication expectations before preparing a report. Do not invent a universal report format or deadline. A useful report can describe what the service tried, which users it reached, where it failed, what changed and what evidence supports improvement. Confidential individual records should not be published casually to demonstrate compliance.

The government has established an Accessibility Advisory Panel to inform guidance and best practice for the APS pilots. Its existence does not mean every recommendation is binding law. The operator should monitor new guidance and consult affected users as the service evolves. If a pilot discovers that a feature consistently excludes a group, it should act on the finding rather than waiting for the next scheduled report.

A service design review before launch

Consider a booked shuttle serving a hospital. The vehicle has a ramp and enough interior space, but the hospital stop is on a narrow pavement and the booking app asks passengers to choose a small map pin. A wheelchair user cannot board safely at that kerb, and a passenger with low vision cannot identify the right pin. The operator's accessibility claim needs to address both problems. It might move the stop, provide an assisted booking channel, change map controls and test the full journey with users. A ramp specification alone would miss the failure.

Now add an unplanned road closure. The vehicle can divert, but the new drop-off point lacks a safe route to the hospital entrance. The operator should know whether it can use the alternative, what the passenger will be told and how suitable assistance is arranged. The permit and local traffic arrangements may also need review. The service should not count the trip as successfully completed simply because the vehicle reached a different nearby road.

A launch review can ask five questions. Can people with different access needs book? Can they reach and identify the vehicle? Can they board and communicate during the trip? Can they leave safely, including after disruption? Can the operator detect and correct failures? Assign each question a named owner, test evidence, open issues and a decision. If a critical element is not ready, limit the service or hold launch rather than describe the gap as future enhancement.

An evidence register for the permit holder

This is an editorial evidence framework, not an official form. The relevant permit holder must check its conditions and applicable passenger, equality, privacy and safety duties. Link the evidence to a specific service version and operating area. An improvement tested on one route may not work at a different kerb or in winter conditions.

Where Complys may fit

A provider may need to track accessibility assessments, passenger feedback, action owners, permit conditions and review dates. Complys could be assessed for administrative evidence management in a demonstration. This article does not claim that it provides accessible booking, dispatches passenger assistance, measures disability outcomes, designs vehicles or prepares statutory reports automatically. The product owner must verify any precise feature statement before publication.

Use a concrete test in the demonstration: a passenger reports that the ramp cannot be used at one stop after roadworks. Ask how the service team would record the issue, connect it to the stop and vehicle, assign an immediate mitigation, preserve test evidence and show that the correction was verified. If bookings, vehicle telemetry or support calls remain in other systems, document the handoff. The AV software overview covers the broader procurement question. The AV checker cannot assess whether a service is accessible.

The useful next step is a journey map tested with disabled and older people, followed by a register of barriers, controls and evidence for the proposed pilot area. Accessibility needs to be demonstrated in booking, at the kerb, inside the vehicle and during disruption. A specialist should review the design and the legal duties; the permit holder should keep learning once people begin using the service.