An accessible museum guide isn't something you bolt onto an existing product after the fact. It's the foundation. And that foundation exists only if your guide lives on the visitor's own device, configured to their own needs, rather than on hardware you control.
This is not abstract accessibility theory. A visitor walking through your museum with a hearing aid, a screen reader, or a specific font size need isn't a niche problem. She's your visitor. And most traditional audio guide hardware was designed before anyone seriously thought about whether disabled people could actually use it.
The fundamental accessibility problem with dedicated hardware
Every audio guide built as a standalone device starts with the same constraint: you've decided how the guide looks, sounds, and responds. The font is what you picked. The text contrast is what you thought was fine. The interface uses the buttons you included. The audio level is what seemed reasonable to you in a production studio.
Now a visitor with low vision sits down to use it. The font is too small. Too light. She needs to increase the size, but the device doesn't support resizing. She can technically listen to the audio, but she also needs the text to follow along, and it's unreadable.
A visitor with hearing loss needs the audio louder and paired with captions. The device doesn't have captions. Volume goes up to a point, but not enough. He gets frustrated and returns the guide.
A blind visitor needs a screen reader to navigate the device interface. Most audio guide hardware doesn't support this at all. The company that built it never tested with blind users. The menus are not labeled. The buttons don't have accessible names. The device becomes unusable.
These aren't edge cases. In a museum seeing 100,000 visitors a year, you're looking at thousands of disabled visitors. Low vision affects roughly 12 million Americans. Hearing loss, 37 million. Blindness, 2 million. These aren't small numbers.
Dedicated hardware solves this problem by making accessibility impossible to add or adjust. Which means it's also impossible for your museum to fail to provide it. But it's impossible the wrong way.
Why BYOD (Bring Your Own Device) is the accessibility solution
A web-based audio guide accessed through a QR code wins the accessibility game before it even starts, because it runs on hardware the visitor has already customized for their own needs.
If a visitor uses a screen reader on her iPhone, your web-based guide works with that screen reader. You don't choose whether to support it. The iOS accessibility framework takes over. If her iPhone has text size set to large, your guide respects that setting. If he's configured his hearing aids to work with specific audio apps, a web-based guide can pair with them. If they've set their phone to dark mode with high contrast, the guide can adapt.
You're not adding accessibility features. You're not fighting against the device's built-in tools. You're not asking the visitor to learn a new interface when they're already expert with theirs. The accessibility work is already done.
This is worth emphasizing: many museums think accessibility means "we added captions." That's part of it. But real accessibility means the guide works with the tools disabled visitors are already using — the assistive technologies they depend on for their entire digital life. A web-based guide integrates with those tools. Dedicated hardware stands apart from them and mostly fails.
WCAG compliance and what it actually means
WCAG (Web Content Accessibility Guidelines) 2.1 at the AA level is the legal and ethical standard for digital products in most countries. For audio guides, that means:
Perceivable: All audio must have transcripts and captions. Video content must have both. Images of artwork need text descriptions, especially for blind visitors who can't see the physical piece in front of them.
Operable: The guide interface must work with a keyboard alone (for visitors who can't use a mouse). Touch interfaces must have sufficient target size. Nothing should require precise timing. Visitors using voice control or switches should be able to navigate.
Understandable: Instructions must be clear. Menu labels must make sense. Error messages must explain what went wrong and how to fix it. This matters for everyone, but it's essential for visitors with cognitive disabilities.
Robust: The guide must work with assistive technologies — screen readers, hearing aids, speech recognition, font-enlargement software. This is a technical requirement that traditional audio guides almost uniformly fail.
Many museums with dedicated audio guide hardware don't meet WCAG AA. Some don't meet WCAG A. They were built before web accessibility standards became mainstream, and the hardware is locked down so accessibility can't be added later.
A web-based guide either meets these standards or it clearly doesn't. There's no middle ground, and there's no excuse for non-compliance. A modern web-based audio guide should default to WCAG AA compliance as a baseline.
Audio descriptions for blind and low-vision visitors
Here's what a blind visitor gets when they enter a gallery with most audio guides: spoken descriptions of what's on the wall, read by an actor or an AI voice. This is better than nothing. But it's also limited by whoever wrote the script.
A good audio description goes beyond basic subject matter. For a painting, it covers composition, color, light, the artist's technique. For a sculpture, it covers form, material, how your body would experience moving around it. For an installation, it covers spatial relationships and how elements interact. An art historian or the artist themselves might write this. Or an AI trained on art history can approximate it well enough to be useful.
But the key is that audio descriptions must be built into the guide from the start. You can't bolt them on afterward. They need to be written with the same care as the main narration. Some museums treat them as an afterthought — a quick summary in a mechanical voice. Others recognize that a blind visitor's experience of the artwork depends entirely on the quality of these descriptions.
A web-based guide makes it easy to record multiple versions of narration (main story, audio description, simplified explanation for children) and deliver the right one based on visitor preference. A dedicated hardware guide would need multiple buttons or menu layers, and many don't even try.
Transcripts and captions for deaf and hard-of-hearing visitors
A transcript isn't a concession. It's a complete alternative to audio. A deaf visitor should be able to experience your audio guide entirely through text — not as an accessibility accommodation, but as a first-class way to engage with the content.
This means transcripts need to be useful, not just accurate. If your narration says "the painting uses warm tones and soft brushwork," the transcript should say the exact same thing. Not a simplified version. Not a summary. The full, rich experience, just in text instead of audio.
Captions for any video content are essential, and they should include descriptions of non-speech audio (music, ambient sound, sound effects). A visitor reading captions needs to know that the scene includes ominous orchestral music or the ambient noise of a busy 1920s street.
Some guides hide transcripts behind an extra button. Better guides make them the default option, letting visitors choose between listening or reading. Web-based guides can even do both at once — hearing the narration while reading along, with text highlighting as the audio plays. This "karaoke mode" turns out to help everyone: tourists learning English, people in noisy environments, and visitors with auditory processing difficulties.
Not everyone navigates with a touchscreen. A visitor with tremors may use a large physical button or a voice-control system. Someone with limited arm mobility might use a switch controlled by head movement. A visitor using a screen reader needs to navigate by keyboard alone.
Your audio guide needs to support all of these. Touchscreens are fine as a primary method, but they shouldn't be the only way. A dedicated hardware guide with physical buttons is actually good here — the buttons don't require perfect fine motor control. But it fails everywhere else: no screen reader support, no voice control, no keyboard navigation because there's no keyboard.
A web-based guide can support keyboard navigation, voice control (through the browser), switch control, and touch all at once. The platform handles it; you don't need to choose one and exclude the others.
Cognitive accessibility and museum fatigue
Walking through a museum is cognitively demanding. Walls of text panels, long narration, making decisions about which direction to go. After about thirty minutes, most visitors stop absorbing information — this is well-documented in museum studies.
Cognitive accessibility means respecting that limit and making information easier to process. Shorter segments. Clear, simple language. Predictable structure. The ability to pause and take breaks without losing your place.
Some audio guides lock you into a linear path. You must experience stops in order. You can't jump around. You can't pause for longer than a few seconds without the guide timing out. These design choices aren't accessibility features. They're the opposite.
A good guide lets visitors navigate non-linearly, pause indefinitely, and choose how much or how little content they engage with. This helps visitors with ADHD, anxiety, or cognitive disabilities. It also helps everyone experiencing museum fatigue.
Simplified language options are often labeled as accessibility features, but they benefit international visitors and anyone not fluent in the guide's language. You're not creating special "easy" content. You're offering the same information at multiple reading levels, the same way some museums offer guides in multiple languages.
Font sizes, contrast, and color considerations
Phone operating systems let users set text sizes. A visitor with presbyopia (age-related vision loss) might have her phone text set to 50% larger than default. Your guide should respect that setting, expanding all text accordingly. Many guides don't — they hard-code font sizes that break when the user changes their system preference.
Text contrast matters. Black text on dark gray backgrounds (or the inverse) fails WCAG standards and causes real difficulty for people with low contrast sensitivity. A modern web-based guide should enforce a 4.5:1 contrast ratio for all body text. This is not optional. It's a baseline.
Color shouldn't be the only way to communicate information. Don't show a visitor that they've selected a stop by changing the button color. Use color plus text, color plus an icon, something that works for colorblind visitors and in high-brightness outdoor environments where colors wash out.
Dark mode isn't an accessibility feature — it's a preference. But building it in doesn't hurt, and it helps visitors who find dark backgrounds easier to read or who want to reduce eye strain in a dark gallery.
Screen readers and semantic HTML
If you're building a web-based audio guide, every interactive element needs a proper accessible name. That button that plays audio? It needs a <button> tag and descriptive text, not a <div> styled to look like a button. That list of stops? It needs <ul> and <li> tags so a screen reader can announce "list of 15 items."
This isn't hard. It's the difference between semantic HTML and broken markup. A web developer who knows anything about accessibility will get this right. A developer who doesn't will build something that technically loads but fails completely for blind visitors.
Test with actual screen readers. Don't assume you know how it sounds. Blind users interact with your guide at hundreds of points where you'd never think to check. They shouldn't have to report bugs. You should find them first.
What dedicated audio guide hardware can't do
This is worth saying directly: there are things a dedicated audio guide device simply cannot do, no matter how well-designed. It cannot integrate with a visitor's own assistive technologies. It cannot adapt to settings a visitor has spent years optimizing. It cannot receive software updates that add accessibility features. It cannot do all of these things simultaneously for different visitors.
Some dedicated guides are excellent. Beautiful hardware, intuitive buttons, great content. But they are less accessible than a web-based guide by design, not by accident. The accessibility limitations are built into the device form factor.
A museum choosing a dedicated audio guide over a web-based one is choosing to exclude disabled visitors. That's not a value judgment on anyone's intentions. It's a structural fact.
What museums can do now
Audit your current guide against WCAG AA. Test the interface with keyboard navigation alone. Turn on a screen reader and try it. Have someone with low vision set their phone's text size to large and see if your guide works. Don't assume it does.
If you have transcripts, make them prominent. Not a hidden link. Not a footnote. A visitor should be able to read along as they listen, with highlighting synchronized to the audio.
Add audio descriptions for artworks and installations. These don't have to be generated by art historians. A well-trained AI can write decent descriptions. The key is that they're written to describe, not to summarize.
Remove timing constraints. If your guide has a logout timer or auto-advance feature, make it optional. A visitor in a wheelchair might move more slowly through the museum and need extra time at each stop.
Choose a guide platform built for the web. Not a mobile app that also works on web. Not hardware with a tablet stuck to it. A web-based guide built to accessible standards from the ground up. BYOD means you're meeting visitors where they already are.
The competitive advantage
Museums are increasingly evaluating vendors on accessibility. Accreditors, funding bodies, and visitors themselves are asking: is your guide accessible? Can a blind person use it? Can someone with hearing loss? Many museums can't answer yes.
An AI audio guide platform built for the web, meeting WCAG standards, working with assistive technologies, designed to complement rather than replace visitor's own device configurations -- that's a competitive advantage. It's not niche. It's what responsible, modern museums are building toward.
If you're evaluating audio guide options and accessibility matters in your strategy, the question isn't whether the vendor claims to be accessible. The question is whether they can demonstrate WCAG compliance, whether they test with disabled users, and whether their architecture makes it possible to add accessibility features over time.
If you want to talk through what an accessible audio guide actually looks like in practice, let's connect.