Switch color mode
Home Blog The Power of Lived Experience in Accessible Design
By the time blind people are invited to test an accessible product, most of the important decisions have often been made.
Danielle Lane
August 7, 2026
The buttons are labeled, the form works with a screen reader, and the audit is clean, so the team feels reasonably confident about it.
When the rubber hits the road, the smaller choices begin to control the experience. Instructions turn out to be three swipes away from the field they explain. Focus jumps after a button press, and an error message announces that something is wrong without making it easy to find. None of this necessarily makes the product impossible to use, which is partly why these problems survive. The blind person using it is still spending more time and attention on the task than sighted users do.
I have been blind since birth and have spent more than a decade working in accessibility and teaching blind people to use technology. A great deal of that work involves products that technically meet the requirements while still making blind people work far too hard for an experience others reach with half the effort.
Automated testing is good at finding known technical failures. It can flag a page with no heading structure, a form field without a label, or a dialog that mishandles keyboard focus. The report records the defect; the person using the product lives through everything the defect causes.
A contact page with poor headings can send a screen reader user through link after link in search of a phone number. When an error message appears far from the field it belongs to, a low vision customer using high magnification may never see it. A modal can open correctly on screen while keyboard focus stays behind it, leaving the user to wonder whether the button did anything at all.
Once these problems are described, they sound obvious. They are much less obvious to a team looking at each component separately, under calm conditions, and with full visual context.
Real customers do not use products that way. They may be tired, in a hurry, unfamiliar with the service, or trying to solve a problem that carries real consequences. The design has to make sense in those conditions, too.
Late-stage testing can identify barriers, but it often arrives after the team has committed to the workflow. Navigation, language, visual design, and technical architecture may all be expensive to change by then.
Earlier involvement gives blind and low vision people room to shape the questions while there is still time for the answers to change the design. A feature that depends on comparing several visual elements may look simple in a prototype, yet require a screen reader user to hold far more information in memory. At high magnification, instructions and controls that appear side by side can become separated by several screens. Those observations can change the design before anyone has to defend the finished version.
This work also needs more than one disabled person approving a product on behalf of everyone else. Blind and low vision people use different technology, have different amounts of sight, and bring different experience to the same task. Research is stronger when that variation is expected rather than treated as inconvenient.
Organizations often invite disabled people to tell personal stories because a specific account can make the consequences of a bad decision harder to dismiss. Our contribution goes much further than illustrating what went wrong.
Blind people build practical knowledge by navigating systems that were not designed with us in mind. We learn where a process is likely to break, which workarounds hold up under pressure, and when a small barrier will make the rest of the task impractical. Someone who uses speech, Braille, magnification, and visual AI may also understand how one design behaves through several very different forms of access.
That knowledge should be paid for and brought into research, design, testing, and support planning early enough to matter. Giving people a finished screen and asking whether it is accessible is a much smaller use of their expertise.
Customer support exposes the limits of accessible design quickly because people rarely contact support when everything has gone according to plan.
A product may have arrived damaged. A device may be showing an unfamiliar error. A customer may need to read a label, identify a control, or check what is displayed on a screen. They might be trying to determine whether the item in front of them is the one they ordered or whether a piece is missing from the box.
The support website can be fully accessible and still leave the central problem untouched. The customer has reached the right place, but the information needed to resolve the issue is visual.
Without a way to share that context, the customer has to describe something they may not be able to see. The agent asks questions based on guesswork, and the customer tries to follow instructions without knowing which visual details matter. A call that should have been straightforward becomes longer, more frustrating, and less likely to end with a clear answer.
The support experience needs to give blind and low vision customers a quick, safe way to share what is in front of them.
Be My Eyes’ Customer Accessibility Suite was built for these situations. Service Connect allows businesses to offer live video support through dedicated agents who can see the customer’s camera and work through the problem with them. The customer can show the damaged product, the device screen, the packaging, or the label rather than trying to reconstruct it verbally.
Service Stream works within a standard support call. An agent who realizes that visual context would help can add a secure video stream to the conversation already in progress. The customer does not have to hang up, switch channels, explain the problem again, or begin a separate accessibility process.
Service AI gives customers immediate access to visual AI for questions that can be answered without waiting for an agent. When the situation is more complicated, sensitive, or uncertain, a live representative remains available.
The value of these products is not limited to whether a customer can technically contact support. They give the customer a better chance of resolving the actual problem while keeping control of the interaction.
A blind customer with a broken appliance or an unexpected message on a medical device does not benefit from a general statement about the company’s commitment to accessibility. They need the support agent to understand what is happening and help them decide what to do next.
That is the difference between providing an accessible route into support and providing accessible support.
Customers notice when a company has thought about what happens after the accessible contact page.
They remember whether they could explain the problem without repeating themselves, whether the agent had enough information to resolve it, and whether the process allowed them to keep their privacy and independence. Families, colleagues, and friends often hear about those experiences, too.
For businesses, this affects more than customer satisfaction. Faster access to the right information can shorten support interactions, reduce unnecessary back-and-forth, and help agents reach a resolution with more confidence. It can also prevent an accessibility failure from becoming a complaint, a lost customer, or a public example of a company failing to meet its own promises.
When customers can share the visual information behind their question and get a useful answer without changing channels or starting over, support works better for everyone involved.
Learn more about the Customer Accessibility Suite or request a demo to see how Service Connect, Service Stream, and Service AI can work with your existing support channels.
