Accessibility in Public Spaces

Duties that start before anyone complains

Equality law does not wait for a disabled resident to meet your robot. The Equality and Human Rights Commission explains that the duty to make reasonable adjustments is anticipatory: an organisation must think in advance, and on an ongoing basis, about what disabled people with a range of impairments might reasonably need. Public bodies also carry the public sector equality duty under section 149 of the Equality Act 2010, which requires them to have due regard to eliminating discrimination, advancing equality of opportunity and fostering good relations. Record how the robot affects people with different impairments in an equality impact assessment before the pilot, and update it once you have real use to learn from.

Robots as obstacles on shared routes

A parked, charging or stuck robot behaves like street furniture, and a moving one can be harder to anticipate. The Department for Transport's Inclusive Mobility guidance, updated in September 2026, sets out best practice for a barrier-free pedestrian environment, including clear widths, tactile paving and the placement of street furniture and obstacles. Use it to decide where robots may travel, wait and charge. Keep them off tactile paving, dropped kerbs and the approaches to crossings, lifts and ramps. Make sure docks and waiting spots do not narrow corridors or footways. A blind person may not know a robot is there until they touch it, so sound and touch cues matter as much as lights.

Robots that people need to use

Service robots that give directions or take requests are part of the service itself, so they must work for disabled customers as well as everyone else. Check that screens sit at a height and angle a wheelchair user can read, that speech is clear and can be repeated, that captions or text accompany every spoken answer and that controls do not depend on fine finger movement. Offer a quick way to reach a member of staff, without forcing anyone through the robot first. Think about people with sensory sensitivities, who may find sudden sounds, bright lights or close approaches distressing, and give the robot quieter settings for calmer times of day.

Testing with the people most affected

Design reviews miss what lived experience catches. Before launch, invite local disability groups and access panels to try the robot in the real building or street, and pay them for their time where you can. Test specific situations: a guide dog user meeting the robot in a corridor, a wheelchair user needing to pass it at a doorway, a deaf visitor asking a question at a busy desk and someone with dementia encountering it without warning. Record what happened and what you changed. After launch, give people an easy way to report problems, publish how you responded and set a date to review whether the robot should stay.

Sources and further reading

• Using a service: reasonable adjustments for disabled people — Equality and Human Rights Commission.
  EHRC explainer on the anticipatory duty to make reasonable adjustments when organisations provide services.
• Public sector equality duty — UK Government, GOV.UK.
  Summary of the duty in section 149 of the Equality Act 2010 and the three aims public authorities must consider.
• Inclusive mobility: making transport accessible for passengers and pedestrians — Department for Transport (UK).
  DfT best-practice guide to barrier-free pedestrian routes: clear widths, tactile paving and street furniture placement.

Common questions

Who is responsible if a robot blocks a disabled person's route?

The organisation that deploys the robot, together with any contractor running it, should expect to answer for it. Set rules for where robots may stop, how fast staff must clear a stuck machine and how the public can report a blocked route, and monitor how often it happens.

What should a robot do when it meets a wheelchair user in a narrow corridor?

It should stop, signal clearly with sound and light, and back away to a wider point if needed so the person can pass. Test this behaviour in your own building and write it into the deployment rules, rather than relying on the maker's default settings.