Physical and digital access requirements
Testing an indoor navigation system with disabled visitors is not a box-ticking exercise carried out once before launch. It is a structured process that reveals whether your beacons, zones, routing logic and interface actually work for people whose physical, sensory or cognitive needs differ from the majority of your design team. The results frequently contradict assumptions made during development.
The core purpose of this testing is to find out whether a disabled visitor can complete a real journey — from entrance to a specific exhibit, seat, till or facility — using the system as it will be deployed, in conditions that match normal operation. That means testing with the actual hardware installed, the app or web interface in its release state, and the venue populated or at least representative of typical footfall.
Disability is not a single user profile. A wheelchair user, a person with low vision, someone who is Deaf, and a visitor with a learning difficulty will each encounter different failure points in the same navigation system. Testing with one group does not validate the experience for another. Equally, within any single impairment category there is considerable variation: not all visually impaired visitors use screen readers, not all wheelchair users have the same turning radius, and not all Deaf visitors prefer the same communication format.
There is a practical distinction between testing for compliance with accessibility standards — which is covered separately in our guide to accessibility standards for indoor wayfinding — and testing for usability. A system can meet a technical standard and still fail a visitor in practice because the route it suggests crosses a floor surface that a wheelchair user finds unnavigable, or because the audio prompt fires too late for someone moving at a slower pace.
Designing equivalent physical and digital journeys
Recruiting test participants
Work through established disability organisations, access panels or user-research agencies with existing relationships in the disabled community. Pay participants fairly for their time and expertise. Avoid relying solely on colleagues or acquaintances who happen to have a disability, as this produces a sample too small and too familiar with your organisation to surface real problems.
Aim for a spread across the impairment types relevant to your venue. A museum with multiple floors and varied exhibit types will need to test with wheelchair users, people with visual impairments, people who are Deaf or hard of hearing, and people with cognitive or learning disabilities. A single-level retail unit with straightforward aisles may have a narrower set of priorities.
Structuring test journeys
Define specific tasks rather than asking participants to "try the app." Examples include: find the accessible toilet on the lower ground floor, locate the lecture theatre and identify the hearing-loop seating, navigate from the main entrance to a specific gallery without using stairs, or find the nearest exit from your current position.
Each task should reflect a journey visitors actually take. Include both common routes and edge cases: the long cross-venue journey, the route that requires a lift, the path that crosses different floor surfaces, and the journey to a little-visited area where beacon density may be lower.
What to observe during testing
- Route selection: Does the system suggest an accessible route without the visitor having to request one? If a manual toggle is required, is it easy to find and does it persist across the session?
- Zone triggers: Do beacons fire at the right point for a wheelchair user, who may approach from a different height and angle than an ambulatory visitor? Does a visually impaired visitor receive the prompt with enough lead time to act on it?
- Instruction clarity: Are turn-by-turn directions unambiguous? Do they reference landmarks that are detectable by the user's senses? "Turn left at the wooden door" is unhelpful to someone with low vision; "turn left after 20 metres" may be more useful, depending on the individual.
- Interface usability: Can a screen-reader user navigate the map and instructions? Are touch targets large enough for someone with limited dexterity? Is there a high-contrast mode, and does it remain active throughout the journey?
- Timing and pace: Does the system assume a walking speed that excludes slower visitors? If the app offers estimated arrival times, are they realistic for a wheelchair user or someone using a walking aid?
- Error recovery: What happens when the visitor takes a wrong turn, loses the signal, or enters a dead zone? Is the recovery instruction accessible, or does it rely on visual cues alone?
Venue and environmental conditions
Test during operating hours, not in an empty building. Other visitors, temporary displays, moved furniture and variations in lighting all affect the experience. If your venue hosts events, test during a live event or a reasonable simulation of one, since crowd density changes how closely a visitor can follow a suggested path and how reliably beacon signals reach the device.
Recording and documentation
Combine direct observation with think-aloud protocols where the participant describes what they are seeing, hearing and deciding at each step. Video or audio recording (with consent) allows the development team to review moments of confusion that may not be captured in written notes. Record the device model, operating system version and any assistive-technology settings in use, as these affect beacon detection and interface behaviour.
Evidence, reasonable adjustments and review
Common mistakes
- Simulating disability instead of involving disabled people. Asking an able-bodied tester to close their eyes or sit in a wheelchair does not replicate the experience, skill or compensatory strategies of someone who navigates with that impairment daily. The results are misleading and can be offensive.
- Testing only in ideal conditions. A system that works perfectly in a quiet, empty corridor at 9 a.m. may fail at midday when the space is crowded, when a pop-up stand blocks the suggested route, or when lighting conditions change.
- Treating the test as a one-off. Venue layouts change. Exhibits rotate. Furniture is moved. A navigation system that passed testing in March may have broken routes by September without any software change.
- Ignoring the journey before and after the digital navigation. If a visitor cannot physically reach the point where the navigation begins — for example, the app download point or the first beacon zone — then the system fails before it starts.
- Aggregating feedback across impairment types. A problem reported by a wheelchair user and a problem reported by a screen-reader user are different issues requiring different fixes. Grouping them under "accessibility feedback" obscures the specific action needed.
Limitations
Sample sizes in accessibility testing are typically small. This is acceptable for uncovering usability problems — a well-established principle in user research — but it means you cannot draw statistical conclusions about the proportion of disabled visitors who will encounter a given issue. Frame findings as "this problem was observed" rather than "X per cent of users will experience this."
Individual variation within impairment categories means that solving a problem for one participant may not solve it for another. A route that works for an electric wheelchair user may be too narrow for a manual wheelchair user with a companion. An audio instruction pace that suits one person with a visual impairment may be too fast for another. Build in flexibility rather than assuming a single accessible configuration will serve everyone.
Beacon-based positioning has inherent variability. A zone that triggers reliably for a tester holding a phone at chest height may behave differently for a wheelchair user whose phone is in a bag or mount, or for someone using a larger tablet. These are not edge cases; they are core scenarios that must be tested with the actual devices and carry positions your visitors will use.
Key checks before, during and after testing
Before testing: Confirm that the beacon firmware, advertising intervals and transmit-power settings match the planned production configuration. Verify that the venue layout in the system matches the current physical layout. Check that any accessibility toggles or preference settings in the app are functional and persist across sessions.
During testing: Note every point where the participant hesitates, backtracks, asks for help or abandons the task. Record the RSSI values or zone-transition logs if your platform exposes them, so you can correlate the user's experience with the signal data. Ask whether the participant would use the system again unprompted.
After testing: Prioritise fixes that prevent a visitor from completing a journey at all, then address issues that cause significant delay or confusion. Re-test with the same participants where possible, since they can confirm whether the fix resolved their specific problem or introduced a new one. Update your indoor map and zone configuration whenever the physical layout changes, and schedule a re-test as part of that process.
