The route barriers hidden by a floor plan
When indoor navigation systems are planned around the assumptions of a mobile, sighted visitor, a significant portion of the audience is effectively excluded from the start. In UK venues — from retail centres and museums to exhibition halls and hospitals — this is not merely an oversight; it creates a system that fails at the point of use for people with visual impairments, mobility limitations, hearing loss or cognitive disabilities.
The core problem is that accessibility is usually treated as a later adjustment rather than a design constraint from the outset. A wayfinding route is mapped, beacons or NFC tags are placed, a digital map is built, and only then does someone ask whether a wheelchair user can actually follow the suggested path, or whether a visually impaired visitor can operate the interface at all. By that stage, the hardware positions, zone definitions and content structure are already fixed, and retrofitting is considerably more expensive than building it in from the start.
Indoor navigation technologies introduce specific accessibility questions that physical signage alone does not. A static tactile map on a wall is a known quantity with established design standards. A Bluetooth-based turn-by-turn system on a smartphone introduces variables: screen reader compatibility, haptic feedback design, the physical placement of NFC touchpoints, the clarity of audio instructions near ambient noise, and whether the system accounts for step-free routes rather than simply the shortest path.
The UK Equality Act 2010 places a duty on service providers to make reasonable adjustments. While the Act does not prescribe specific technical standards for indoor navigation, a system that cannot be used by a disabled visitor is difficult to defend as a reasonable provision of service. The practical risk is not only regulatory but reputational: a venue that publicly launches an innovative wayfinding system which a portion of its visitors cannot use has created a visible symbol of exclusion.
Translate access needs into system requirements
Route logic and physical space
The most fundamental accessibility failure in indoor navigation is route logic that ignores the physical reality of the building. A system that directs a visitor through a staircase because it is the shortest path has failed for anyone who cannot use stairs. The navigation engine must be capable of accepting accessibility constraints — step-free routes, lift access, avoiding narrow corridors or turnstiles, and routing around temporary obstacles like steps or closed lifts — and applying them per user preference.
This requires the underlying map data to include accessibility attributes for every segment: whether a corridor is wide enough for a wheelchair, whether a door is automatic or requires manual operation, where lifts are located and whether they are currently operational. If the venue management system feeds lift status into the navigation platform, a broken lift can trigger an automatic reroute rather than directing a mobility-impaired visitor to a non-functioning lift.
Visual impairment and interface design
For visitors who are blind or partially sighted, the wayfinding interface must work with screen readers such as VoiceOver on iOS or TalkBack on Android. This is not automatic. If the navigation app or web view uses custom gesture controls, unlabelled buttons or dynamic content that does not trigger screen reader announcements, the system is unusable regardless of how accurate the underlying positioning is.
Audio instructions present their own design challenges. Turn-by-turn directions must be clear enough to understand in a noisy exhibition hall or retail environment. The timing of announcements matters: too early and the visitor has forgotten by the time they reach the decision point; too late and they have already passed it. Haptic feedback — vibration patterns indicating left, right or straight ahead — can supplement audio in loud environments, but only if the device supports it and the app implements it correctly.
NFC and QR placement
NFC tags and QR codes used as wayfinding touchpoints must be physically accessible. A QR code mounted at eye level on a glass panel is of no use to a wheelchair user or a child. An NFC tag embedded in a surface that requires precise hand placement is difficult for someone with limited dexterity. Placement height, reach distance, angle and contrast against the background are all practical decisions that determine whether the touchpoint serves the whole audience or only a subset.
For visually impaired visitors, NFC is generally preferable to QR because it does not require visual targeting — the user brings the phone close to a known physical location. However, this advantage disappears if the NFC tag is unmarked, poorly positioned or inconsistent in its placement across the venue.
Hearing impairment
Visitors who are deaf or hard of hearing may rely on visual wayfinding cues. If the system's primary output is audio, with no visual alternative, it has not accounted for this audience. Visual turn indicators on screen, text-based directions and vibration alerts are necessary complements. Where the venue uses hearing loops, the navigation system should not interfere with loop frequency bands, though this is primarily a hardware integration concern for the venue's AV team.
Cognitive accessibility
Some visitors process spatial information differently. Overly complex instructions, rapid sequential turns or interfaces cluttered with non-essential information can make the system difficult to use for people with cognitive disabilities or learning difficulties. Clear, simple language, the option to repeat instructions, and the ability to reduce the interface to essential elements only are practical design choices rather than optional enhancements.
Monitor changes that can break accessibility
Assuming compliance equals accessibility
Meeting WCAG guidelines for the digital interface is necessary but not sufficient. A navigation app can pass a WCAG audit and still be inaccessible if the routes it suggests are physically impossible for a disabled visitor, or if the beacon placement means positioning accuracy degrades precisely in the areas where accessible routes diverge from standard routes — for example, near lifts that are set back from main corridors.
Testing only with able-bodied users
Pilot programmes frequently test with the project team or a sample of typical visitors. If no participant uses a wheelchair, a screen reader or a hearing aid, the pilot will not reveal accessibility failures. Involving disabled users in testing — ideally people who are regular visitors to the type of venue, not just accessibility consultants — is the only reliable way to uncover real problems. This should happen during the pilot phase, not after full deployment.
Placing hardware without accessibility in mind
Beacons mounted high on ceilings for optimal signal propagation may work well for positioning but are irrelevant if the associated NFC touchpoint is out of reach. Conversely, lowering a beacon to improve NFC access may reduce its effective range and create dead zones. Hardware placement is a trade-off, and accessibility requirements must be part of that calculation from the start, not an afterthought discovered during installation.
Ignoring environmental variability
Accessibility features that work in a quiet, empty corridor may fail in the real operating environment. Audio instructions that are clear during a morning test may be unintelligible during a busy Saturday afternoon. A route that is step-free on a Tuesday may be blocked by a temporary exhibition build on a Thursday. The system needs to account for, or at least warn about, environmental conditions that disproportionately affect disabled visitors who have fewer alternative routes available.
Key checks before deployment
- Can a wheelchair user complete every major route the system suggests without encountering stairs, narrow gaps or manual doors that cannot be operated independently?
- Does the interface work fully with VoiceOver and TalkBack, including dynamic route updates and rerouting notifications?
- Are NFC touchpoints and QR codes placed between 900mm and 1200mm from finished floor level, with clear visual and tactile contrast?
- Can all audio instructions be supplemented or replaced by visual and haptic output?
- Has the system been tested with disabled users in realistic operating conditions, not just quiet periods?
- Does the route engine support per-user accessibility preferences, rather than applying a single routing logic to all visitors?
- Are lift statuses and accessible facility availability reflected in real-time routing, or does the system assume static building conditions?
- Has the venue's accessibility officer or equivalent been involved in reviewing the proposed zone definitions and hardware placement?
Accessibility is not a feature to be added once the system works for everyone else. In indoor navigation, it is a structural requirement that affects route data, hardware placement, interface design and testing methodology. Ignoring it does not produce a system that works for most people and needs minor adjustments; it produces a system with a defined group of users for whom it simply does not work.
