Who are digital bus services designed for?
Digital bus services should work for the passengers who rely on them, including those who cannot or do not want to depend on a smartphone or contactless payment. They should make bus travel easier for disabled passengers.
People search for
We have seen this pattern in several design reviews. Nobody sets out to exclude anyone. Teams often picture a passenger who is comfortable with apps and overlook others. A ticket menu may assume that a passenger understands the Authority's fare names.
Consider a woman in her late seventies who no longer drives. She uses the bus for shopping, appointments and visits to her grandchildren. She owns a smartphone but is not confident using it. If she selects the wrong ticket, she needs to understand what has happened and find a clear route back.
A passenger who uses a screen reader every day can be blocked by an unlabelled button. Small controls on a moving vehicle may be difficult for someone with limited hand movement. A passenger with a flat or broken phone needs another way to travel. An Authority should expect all these passengers on its network.
Where the journey breaks
Accessibility is sometimes treated as a specialist app check, although it also affects fare design, disruption information, refunds and customer contact. A passenger may complete the main ticket-purchase flow yet be unable to read a disruption notice or request help when a payment fails.
Many of the same choices improve the service for more passengers. Clear ticket names help somebody with a learning disability and someone buying at a busy stop. Visual versions of audio alerts help passengers travelling in a noisy vehicle.
| Passenger situation | Practical design response | Evidence an Authority can ask to see |
|---|---|---|
| Low confidence with digital services | Familiar terms, plain ticket names and an obvious way to recover from an error | Observation of people choosing a ticket and correcting a mistake |
| Visual impairment | Meaningful labels, logical keyboard focus and instructions not conveyed by colour alone | Technical review and task testing using relevant assistive technology |
| Limited hand movement | Controls that are adequately sized and spaced, without fine gestures as the only route | Target-size checks and observation on a handheld device |
| Learning disability or cognitive impairment | Short instructions, predictable pages and a clear next action | Testing whether priority tasks and messages are understood |
| Hearing loss | A visual equivalent for operational audio information | Checks of alerts, help and disruption information |
| Non-working smartphone | A usable telephone, paper or in-person channel | Opening hours, staff instructions and a completed test of the alternative journey |
Alternative channels do not make an inaccessible app acceptable. They can, however, determine whether a passenger is able to travel when a device is unusable. If an Authority offers them, it should check that they work at the hours and in the situations in which passengers need them.
Standards and passenger evidence
For public-sector websites and mobile apps within scope of the accessibility regulations, the expected technical standard is WCAG 2.2 Level AA, supported by an up-to-date accessibility statement. An Authority remains responsible if a Supplier builds or runs the service. It should therefore specify the requirement in procurement and maintain it through the contract.
The wording of individual requirements matters. WCAG 2.2 includes a Level AA requirement on pointer target size: controls should provide a target of at least 24 by 24 CSS pixels, subject to exceptions, including sufficient spacing around a smaller control. Larger, well-spaced controls may be sensible for a bus app used at a stop or on board.
A technical conformance review and passenger testing answer different questions. The review checks the product against the standard; testing shows where people have difficulty completing a real task. The findings from a small group should not be treated as proof of every disabled passenger's experience.
Ask the Supplier to show the version tested, tasks used, devices and assistive technologies involved and faults found. Ticket selection, payment recovery and disruption information are more useful test tasks than a generic walk-through. Where a fault remains open at launch, record the owner, interim arrangement and retest date.
The LiteFranchise™ Accessibility Action Plan and Equality Framework gives Authorities a structure to record these questions and follow through on the answers. Whatever framework they use, evidence should remain linked to a passenger task and the person responsible for resolving the issue.
Alternative channels do not make an inaccessible app acceptable, but they can decide whether a passenger travels at all.
Useful questions
Before accepting a design or Supplier assurance, ask:
- Which passenger tasks have been tested from start to finish and who took part?
- What evidence supports the WCAG 2.2 Level AA assessment and does it cover the current release?
- Where testing found a barrier, who owns the change, what is the interim arrangement and when will it be retested?
- Can a passenger report an accessibility problem without relying on the part of the service that is causing the problem?
- Do the telephone, paper and in-person alternatives work during the hours and circumstances in which passengers may need them?
More on Accessibility & Inclusion
