User needs that must shape the design
Accessibility in indoor navigation means more than step-free routes and lift access. It covers the full range of ways visitors perceive, process and move through a space: visual impairment, hearing loss, mobility differences, cognitive and learning disabilities, and neurodivergent needs. Proximity technologies such as Bluetooth beacons, NFC tags and QR codes can support many of these requirements, but only when they are planned as part of a broader inclusive strategy rather than bolted on afterwards.
The Equality Act 2010 requires service providers to make reasonable adjustments. In practice for museums and venues, this means anticipating a range of visitor needs and removing barriers where possible. Indoor navigation technology is one tool among many: it does not replace physical accessibility improvements, clear signage, trained staff or hearing loops, but it can supplement them in ways that significantly improve the visitor experience.
A useful framing is to think of inclusive navigation as offering multiple parallel channels for the same information. A sighted visitor might read a wall label or a visual map. A visually impaired visitor might receive audio directions triggered by a beacon. A visitor who struggles with written text might prefer a simple pictorial route on their phone. The underlying spatial data is shared; the presentation adapts.
It is also worth recognising that inclusive design often benefits visitors without declared disabilities. Someone with a broken arm, a pushchair, or simply a dead phone battery will appreciate alternatives that were originally planned for accessibility. Designing for the widest range of users tends to produce more robust systems overall.
Make alternatives part of the core service
Visual Impairment and Audio Wayfinding
Bluetooth beacons are frequently used to trigger audio descriptions or directional prompts as a visitor moves through gallery spaces. The visitor typically carries a smartphone running the venue's app or a web-based interface, with screen reader software enabled. When the device detects a beacon near a particular exhibit or junction, it can announce the location, describe what is nearby and offer turn-by-turn guidance.
NFC tags offer a different interaction model: the visitor deliberately taps a physical tag with their phone. This gives the visitor control over when information is delivered, which some people prefer over automatic triggers. Tactile markers placed beside NFC tags help visitors locate them without sight.
QR codes are less suitable as a primary channel for visually impaired visitors because scanning requires aiming a camera at a specific point. However, a companion can scan on the visitor's behalf, and the resulting content can still be screen-reader compatible if the linked page follows web accessibility standards.
Mobility and Route Planning
Visitors using wheelchairs, mobility scooters or walking aids need to know where lifts are, which corridors are wide enough, where ramps exist and where seating is available along a route. Indoor navigation systems can store this information as route attributes and filter options accordingly. A visitor selecting a "step-free route" should receive a path that avoids stairs, even if it is longer.
The practical challenge is maintaining accurate data. Lifts break down. Corridors get temporarily obstructed. If the system does not reflect current conditions, it risks directing a visitor to a blocked route, which is worse than offering no digital guidance at all. Some venues address this by linking navigation data to a simple back-end status feed that staff can update when a lift is out of service.
Cognitive Accessibility and Information Load
For visitors with learning disabilities or cognitive differences, the priority is simplicity and clarity. Long paragraphs of text, complex branching menus and frequent notifications create barriers rather than remove them. Practical measures include:
- Offering a simplified interface option with fewer choices and larger touch targets
- Using clear, concrete language rather than abstract descriptions
- Limiting the number of notifications per visit to avoid overwhelming the user
- Providing consistent, predictable behaviour: the same type of trigger should always produce a similar type of response
Beacon-triggered notifications need particular care here. If a system sends an alert every few metres, a visitor with cognitive accessibility needs may find the experience stressful rather than helpful. Defining quiet zones and setting sensible frequency caps are not just good practice for general users; they are accessibility requirements for some audiences.
Hearing Impairment
Visitors who are deaf or hard of hearing may miss audio announcements, guided tour commentary or spoken directions. Indoor navigation can help by providing text-based alternatives: written directions, visual maps with highlighted routes, and captions or transcripts for any audio content triggered by beacons or NFC. If the venue uses audio beacons for general announcements, a parallel text push notification ensures hearing-impaired visitors receive the same information.
Verify complete journeys in realistic conditions
Assuming One Technology Serves All Needs
A frequent error is deploying a single technology, typically QR codes, and describing the result as "accessible." QR codes require vision, a working camera and sufficient lighting. They exclude visitors who cannot see the code or cannot hold a phone steady. An inclusive system usually combines at least two channels: for example, NFC for deliberate tactile interaction and beacons for passive audio cues, with QR as an additional option for those who find it convenient.
Not Testing With Disabled Visitors
Internal testing by the project team, however well intentioned, rarely surfaces the real barriers. A beacon that triggers reliably for a developer holding a phone at chest height may not work for a wheelchair user whose phone is in a bag, or for someone using a mounted device. NFC tags placed at standard adult height may be unreachable from a seated position. The only reliable way to catch these issues is to include disabled people in pilot testing, ideally through organisations with relevant expertise rather than ad hoc recruitment.
Ignoring the Physical Environment
Technology does not exist in a vacuum. NFC tags placed on reflective glass surfaces may not read consistently. QR codes positioned in dimly lit corridors are difficult to scan. Beacon signals in spaces with heavy metal fixtures, thick stone walls or large crowds behave differently from those in open plan areas. Accessibility planning must account for the actual physical conditions of the venue, not just the technical specifications of the hardware.
Letting Content Drift Out of Sync
An accessible navigation system is only as good as the content it delivers. Audio descriptions that refer to objects that have been moved, text directions that mention doors that have been locked, or links that lead to error pages all undermine trust. For visitors who depend on the system as their primary way of navigating, broken content is not a minor inconvenience; it can leave them disoriented or unable to reach their destination. Content maintenance schedules should be built into the operational plan from the start.
Key Checks Before Deployment
- Has the system been tested with screen readers on both iOS and Android devices?
- Are NFC tags mounted at a height reachable from a seated position, with tactile indicators beside them?
- Do step-free routes in the navigation system reflect the current physical layout, including temporary closures?
- Is there a cap on notification frequency to prevent overload for visitors with cognitive accessibility needs?
- Are all audio triggers accompanied by text alternatives for visitors who cannot hear?
- Has the web content triggered by QR codes or NFC been tested against WCAG guidelines?
- Is there a clear, non-digital fallback for visitors who cannot or choose not to use a smartphone?
- Have disabled visitors been involved in pilot testing, and has their feedback been acted upon?
Inclusive navigation is not a feature to be added at the end of a deployment. It shapes decisions about which technologies to use, where to place hardware, how to structure content and how to maintain the system over time. When it is treated as a core requirement from the outset, the result is a more usable system for everyone.
