A Monday morning outpatient appointment can expose the limits of a conventional navigation app. A partially sighted visitor arrives at an NHS hospital, needs Clinic 4B for a 09:40 appointment, finds that the lifts are being maintained, and sees signage pointing only towards the radiology corridor. A blue dot that drifts near the stair core won't solve the problem. The visitor needs an accessible route, clear instructions, and confidence that the final doorway is the right one.

That is why an indoor navigation SDK should be assessed as operational accessibility infrastructure, not just as a positioning component. The strongest procurement decisions test route completion, correct-door arrival, map freshness, sensor resilience, privacy, and the organisation's ability to maintain accessibility data after launch.

What an Indoor Navigation SDK Actually Does in a UK Venue

In that hospital scenario, the SDK should load the trust's floor data, identify the visitor's starting point, and calculate a route that avoids the unavailable lifts. It should understand the difference between a public corridor, a staff-only connection, a stair, a step-free entrance and a temporary closure. The resulting guidance should appear inside the trust's own app or a white-label mobile experience, rather than forcing the visitor to adopt an unrelated service.

A useful SDK has three connected layers:

1. A walkable map graph that stores corridors, doors, rooms, stairs, lifts, platforms, entrances and accessibility attributes.
2. A localisation engine that estimates the user's position, heading and confidence from available phone signals and sensors.
3. An interaction layer that exposes search, routing, turn-by-turn instructions, audio, haptics, screen-reader support and rerouting through the venue's existing digital product.

The route engine matters as much as the location estimate. If the lift status changes, the SDK must remove that connection from the graph and offer an alternative. If the user's confidence falls near a stair core, it should avoid issuing a precise instruction that the system can't support.

The data model decides whether guidance is useful

A floor plan alone isn't enough. Procurement teams should ask whether the SDK can consume the trust's own plans and convert them into navigable paths, then attach temporary and permanent accessibility information to the relevant route segments.

That includes:

• Step-free paths through entrances, corridors and floor changes.
• Decision points at doors, junctions, ticket barriers, crossings and platforms.
• Temporary exceptions such as closed lifts, construction hoardings and relocated reception desks.
• Points of interest with unambiguous descriptions, including clinic doors, toilets and help points.
• Interaction preferences for VoiceOver, TalkBack, high contrast, enlarged text, audio and haptic guidance.

The Waymap wayfinding app example illustrates the product layer buyers should expect to embed into a branded experience. The important procurement question isn't whether the map looks polished. It's whether the SDK can turn live venue data into instructions that remain understandable when the building changes.

Sensor Fusion and the PDR Pipeline Buyers Should Expect

A UK-relevant SDK should use pedestrian dead reckoning, or PDR, as a staged sensor-fusion pipeline. UK academic work identifies the phone's accelerometer, gyroscope and magnetometer as core inputs, while research from the University of Glasgow describes particle filtering and sensor-data fusion as ways to reduce accumulated positioning error. The Glasgow research paper also makes the central engineering issue clear: drift grows when small heading and step-length errors accumulate.

A credible pipeline should include these stages:

1. Bias calibration for the accelerometer and gyroscope.
2. Step detection from acceleration peaks and movement patterns.
3. User-specific step-length estimation, rather than a fixed population average.
4. Heading integration from inertial orientation.
5. Map matching or particle filtering against the digitised venue graph.
6. Confidence-based recalibration when the estimate becomes unreliable.

What buyers should make vendors demonstrate

Magnetic interference near lift shafts can distort heading. Long corridors expose IMU bias and step-length drift. A wheelchair user may propel in a way that doesn't create the expected walking signature, while a person carrying a bag or using a cane may produce a different motion pattern. A system that performs well for a steady walking test can still fail in a crowded Underground interchange.

Buyers should ask to see position, heading, confidence, mode switches, stationary-period detection and recalibration events in the SDK telemetry. The integration team needs enough visibility to explain why guidance changed and to identify whether a failure came from the sensor estimate, route graph or venue data.

Beacon and Wi-Fi systems can still be appropriate. The trade-off is not only accuracy versus cost. It includes installation, survey effort, battery or network dependencies, maintenance after a ward moves, and behaviour during a power or connectivity outage. Teams assessing enterprise wireless requirements may find Purple's enterprise WLAN overhead tool useful when estimating the operational implications of infrastructure-based positioning.

A useful sensor-fusion algorithm explanation should be accompanied by a live demonstration. Ask vendors to test different phones, speeds, canes, wheelchairs, bags and crowd conditions, not only static-position accuracy.

Why Accuracy Is the Wrong Headline Metric for UK Deployments

A vendor can quote a small positioning error and still deliver a poor wayfinding service. A user may be located near the right corridor but directed through the wrong entrance, miss a turn at a concourse, or arrive at the wrong side of a platform. For a blind or partially sighted traveller, those failures can lead to assistance requests or abandonment even when the blue dot appears plausible.

The more useful outcome is independent journey completion. The University of Southampton study involving UK participants with visual impairment found that 70% to 87% lacked confidence in wide-open areas, hallways or large rooms, and that up to 70% reported moving obstacles such as people and trolleys as barriers. The Southampton study supports a practical acceptance test: evaluate guidance through open spaces and around moving obstacles, not only along a quiet corridor.

Test the destination, not just the estimate

RNIB's research found that more than half of blind and partially sighted people struggle to find their way through public-transport facilities, while more than three quarters feel nervous travelling to unfamiliar places. RNIB's February 2025 journey research points buyers towards metrics that reflect lived experience:

• Journey completion without unplanned assistance.
• Correct turns at named decision points.
• Arrival at the correct door, platform, bus stop or clinic.
• Rerouting after a lift closure or operational change.
• Missed turns, unsafe stops and assistance requests.
• Confidence, measured separately from technical location accuracy.

Test scenarios should include finding a step-free path from a gateline to a platform, locating a side entrance after a ward refurbishment, and reaching a venue exit when the usual route is unavailable. Keep the route and user conditions consistent enough to compare suppliers, but include blind and low-vision participants in the evaluation itself.

A headline metre figure can remain useful as a diagnostic measure. It just shouldn't be the procurement outcome. The test should establish whether the system helps a person reach the intended destination safely, independently and with understandable instructions.

Evaluation Criteria for Comparing Indoor Navigation SDKs

Procurement teams should score an SDK against the service they need to operate, rather than accepting a vendor-supplied accuracy presentation. A structured scorecard makes trade-offs visible to estates, digital, accessibility, information governance and commercial stakeholders.

A pass threshold should be written as observable evidence, not as “best in class”. For example, ask the supplier to show how a lift closure enters the data model, reaches the route engine and appears in the user interface. Ask who approves that change and how the organisation proves it was published.

Teams building a broader sourcing process can use vendor selection for engineering teams as a complementary framework. For the navigation decision itself, Waymap's vendor selection criteria is a useful prompt to include accessibility outcomes and operational ownership alongside technical fit.

Integration Steps From Pilot to Live Deployment

A successful pilot starts with a narrow operational question. A hospital might ask whether visitors can reach a clinic from a public entrance without staff intervention. A metro operator might test the route from a street entrance to a step-free platform. A stadium may begin with one concourse and a small set of accessible points of interest.

Start with evidence, not a large map

Begin by defining the venue and accessibility brief. Record entrances, decision points, lifts, stairs, tactile paving, crossings, toilets, help points, platform edges and staff-only areas. Then run a bench evaluation against recorded inertial traces before committing to a full site deployment. This exposes integration and telemetry gaps early.

The practical sequence is:

1. Scope the venue and user groups. Define the buildings, floors, route types and accessibility outcomes.
2. Run a bench evaluation. Compare the SDK with recorded movement traces and agreed failure scenarios.
3. Build a single-wing proof of concept. Validate route logic, turn instructions and confidence handling with real users.
4. Author the floor data. Convert plans into a walkable graph and annotate accessible features.
5. Survey supporting hardware if needed. Check beacon locations, Wi-Fi coverage and radio conditions rather than assuming the building is uniform.
6. Integrate and test. Connect the SDK to the existing app or native shell, then test VoiceOver, TalkBack, high contrast, audio and haptic modes.
7. Scale with a maintenance owner. Expand across buildings only after the update workflow and acceptance tests are operating.

Common pilot failures

Outdated floor plans cause more trouble than an imperfect interface. Lift-only accessible routing also fails when the system doesn't receive maintenance status. Missing accessible-toilet, entrance or reception data creates a polished route to an incomplete destination.

Budget the integration as a real engineering workstream, with effort varying according to the venue's map quality, number of buildings, app architecture and operational integrations. Don't accept an estimate that excludes accessibility user testing, map authoring, data governance or post-launch change management. The implementation best-practices guidance should be considered alongside the venue's own estates and digital-service procedures.

Map Data, Maintenance, and the Accessibility Lifecycle

An indoor navigation SDK is not a one-off installation. Hospitals move departments, transport operators close entrances, lifts fail, construction routes change and accessible facilities become unavailable. If the map team treats launch as the finish line, users will eventually receive instructions that are technically generated but operationally wrong.

Consider a representative UK hospital deployment. The digital team integrates an SDK into the trust's visitor app, while estates staff maintain the underlying map through a controlled editor. A lift closure enters the estates workflow, the accessibility exception is approved, and a CMS feed updates the route graph. The app then avoids the lift and explains the alternative route rather than sending visitors towards a closed connection.

That workflow only works when ownership is explicit. The trust needs to know who can edit a route, who approves a change, when it becomes live, which map version generated a journey, and how a correction reported by a disabled visitor is investigated.

Treat accessibility data as operational data

RNIB's bus research found that fewer than half of blind and partially sighted people could make all the bus journeys they wanted or needed to make, while 83% said having the option to travel by bus was very important and 95% used buses at least monthly. The same RNIB report on bus travel and sight loss found that 49% made fewer journeys to avoid bus-stop bypasses. These findings make the map lifecycle a service-quality issue, not an internal content task.

A route model should therefore support:

• Version control. Keep a record of the floor, route graph and accessibility attributes used for each published release.
• Change triggers. Connect lift maintenance, construction, room moves and entrance closures to a defined map-update process.
• Regression testing. Re-test important routes after every structural change, especially floor transitions and step-free connections.
• User-reported corrections. Give visitors and staff a clear way to report a blocked route, wrong door or misleading instruction.
• Scheduled accessibility audits. Recheck entrances, lifts, ramps, toilets, tactile features and platform information with disabled users.

The public interface should publish route coverage, update timestamps, known exceptions and escalation options. The Southampton evidence on open areas and moving obstacles also means that a map audit can't replace practical route testing. A corridor may be represented correctly while the experience at its junction remains difficult.

Procurement needs an exit and privacy plan

The contract should specify map-freshness responsibilities, publishing targets, audit trails, support response, data portability and an exit process if pricing or terms change. It should also define which analytics are collected, whether processing occurs on the device, how long event data is retained, and which party completes the UK GDPR data-protection impact assessment.

WCAG 2.2 AA and ETSI EN 301 549 should appear in the evidence request, but conformance statements aren't enough. Require test reports for the actual branded app, including VoiceOver, TalkBack, keyboard interaction where relevant, text scaling, contrast, audio controls and error recovery. Public-sector teams should also align the service with the expectations of their wider accessibility and geospatial data governance processes, including PSGA-style requirements where those apply to the organisation.

RNIB's Outlooks research found that 57% of participants said moving through streets and public spaces would have a huge positive impact on quality of life, while only 17% felt able to do so. It also found that 61% did not use technology or did not have technology to help them move around and get around outside. The RNIB Outlooks report is a useful reminder that an app doesn't automatically create independence. The service must be discoverable, usable, trusted and supported by announcements, signage, staff assistance and non-digital alternatives.

Three actions belong in this quarter's procurement plan:

1. Define a map-freshness service level for permanent and temporary accessibility changes.
2. Require documented testing with blind and partially sighted users, including journey completion and confidence.
3. Insist on a data-processing agreement that limits collection and favours on-device processing where possible.

Frequently Asked Questions From UK Procurement Teams

How does an indoor navigation SDK work without BLE beacons?

An indoor navigation SDK can use phone-native inertial sensors and a digitised venue map without requiring installed BLE beacons. The SDK estimates movement through PDR, constrains the estimate against walkable paths, and recalibrates when confidence falls.

That approach can reduce the physical maintenance burden, but it doesn't remove the need for high-quality map data and route testing. Buyers should test long corridors, lift cores, open concourses, different walking styles and temporary closures.

What accessibility conformance should buyers require?

Buyers should require evidence against WCAG 2.2 AA and ETSI EN 301 549, then validate the integrated service with disabled users. The evidence should cover the SDK's controls, the host app, VoiceOver, TalkBack, audio guidance, text scaling, contrast and route-content quality.

The public-sector procurement guidance should sit beside a practical acceptance plan. Include correct-door and platform arrival, missed turns, assistance requests and confidence, not only interface inspection.

How is map data kept current after launch?

Map data stays current when estates, accessibility and digital teams share a controlled update workflow with versioning, approvals, testing and an audit trail. Lift closures, construction routes, room moves and entrance changes should trigger a defined update rather than relying on an annual map refresh.

The operator should be able to report the current map version, known exceptions and update timestamp to users and staff.

What data-protection posture should a UK organisation expect?

A UK organisation should expect a clear data-flow diagram, a DPIA process, data minimisation, defined retention, processor terms and an explanation of on-device processing. The vendor should identify what location and diagnostic events are collected and why.

RNIB's evidence on unfamiliar journeys, public-transport facilities and technology adoption provides a stronger benchmark for user research than a positioning slide deck. Procurement teams should use that evidence to assess whether the service supports independent travel in the environments where users need it.

Waymap provides an SDK that embeds its smartphone-sensor navigation engine into an existing branded app, with step-by-step guidance across indoor, outdoor and underground environments without GPS, Wi-Fi, Bluetooth beacons or mobile signal. Visit Waymap to discuss a UK venue pilot focused on route completion, accessible data governance and operational resilience.