A screen reader reaches a chart, a diagram or an equation and simply goes quiet.

The surrounding text may be perfectly readable, but the part that actually explains the subject is missing. You can access the document without being able to understand it.

That was the problem facing Mark Morad, a blind Egyptian student who went on to create ScribeMe, an artificial intelligence-powered accessibility app. According to reporting by Reuters, published by CNA, Mark contacted developers working on similar problems but received no replies. He then taught himself to code.

By 2023, he had a working app.

I find this story interesting because it shows what changes when lived experience is treated as useful product knowledge, rather than something to consult at the end.

The real requirement was easy to miss

A sighted developer looking at a physics textbook might decide it is accessible because the text can be extracted and read aloud.

A blind student gets a different version of that product.

The text is available, but the chart carrying the argument is silent. The diagram showing how two ideas relate to each other is absent. The equation may be read as a confusing string of symbols rather than meaningful maths.

Some of the content has been provided, but the student still cannot complete the task.

I see this distinction repeatedly in digital accessibility. Standards and automated checks are valuable, but they cannot tell you whether somebody can understand the information, make a decision and get something done independently.

Mark knew what the product needed to do because he had encountered the failure himself. The question was not simply, “Can software recognise this text?” It was, “Can a blind person understand the whole document?”

That is a much better requirement.

From documents to the world around you

ScribeMe has since grown beyond document scanning. It can describe images, answer questions about what a phone camera can see and provide continuous descriptions of a user’s surroundings.

The app is available on iPhone and Android and can also work with Meta’s AI glasses. This makes the experience hands-free.

That may sound like a small interface improvement. It isn’t.

I use a white cane as well as assistive technology. A product that expects a blind person to hold a phone in front of them while walking creates an immediate practical problem. One hand may already be doing a rather important job.

Putting the camera into a pair of glasses changes how the feature can be used. The phone can stay in a pocket, the user can continue using a cane and spoken information can be delivered while they move.

The current ScribeMe website describes continuous live assistance, object detection, document scanning and video audio description. It also lists support for languages including Arabic, Hindi, Spanish, French and Japanese.

Reuters reported that the app was being used across 140 countries. The report also highlighted Arabic support as a gap Mark had found in competing products.

That is another requirement product teams often miss.

Accessibility does not stop at the interface. Language, location and cultural context all affect whether someone can use a service. A technically impressive product that works only in a few dominant languages is not a global accessibility solution.

Lived experience is professional expertise

Stories about people with disabilities creating new technology are often presented as inspirational.

That framing can obscure the more useful point.

Mark identified unmet requirements, developed a product and entered a market. His experience gave him a clear view of problems that other developers had overlooked or chosen not to address.

That is expertise, not inspiration.

Many organisations involve people with disabilities late in development. They ask them to test a nearly finished product, identify barriers and validate decisions that have already been made.

Late testing can still improve the result, but it is a limited and expensive use of people’s knowledge.

By then, the team may have selected the wrong platform, committed to an unsuitable interaction model or designed the feature around assumptions that are difficult to reverse. Testing will reveal the consequences. It will not make those early decisions cheap to undo.

People with disabilities need to be involved while the problem is still being defined.

They can help a team decide:

• what a successful outcome should be;
• which information the user actually needs;
• where automation might help or introduce risk;
• what independent use looks like in practice;
• which languages, devices and assistive technologies need supporting;
• how users recover when the AI gets something wrong.

The last point is especially important.

What happens when the AI is wrong?

AI-generated descriptions can make previously inaccessible information available. They can also be incomplete, inaccurate or extremely confident about something they have misunderstood.

For a blind user, the consequences vary.

Getting the colour of a shirt wrong is irritating. Misdescribing a platform edge, traffic signal, medicine packet or unfamiliar environment could be dangerous.

Products in this area need more than an impressive demonstration. Users need clear information about what the system can and cannot reliably do. They need privacy controls, accessible ways to challenge or correct mistakes, and a route to human assistance when the consequences of an error are serious.

Testing also needs to happen in the environments where people will use the product.

A well-lit object sitting neatly on a desk is one thing. A busy railway station, poor mobile connection, overlapping conversation or moving vehicle is something else entirely.

I am positive about the possibilities here, but enthusiasm should not remove scrutiny. The more we expect people to rely on these tools, the more their accuracy, safety and transparency matter.

Bring people in before the testing starts

The lesson from ScribeMe is not that people with disabilities should have to build their own tools whenever the market lets them down.

They should not.

The lesson is that lived experience exposes requirements that conventional product development can miss. Organisations can use that expertise early, or discover the same problems later through remediation, customer frustration and lost trust.

People with disabilities should be involved as researchers, designers, developers, decision-makers and founders. They should help choose which problems are worth solving, not just test somebody else’s answer.

ScribeMe began with a blind student trying to access information that his existing tools could not explain.

If someone with that experience joined your product team, when would you involve them?

If the answer is “during accessibility testing”, you have probably left it too late.

Source: Blind Egyptian entrepreneur’s AI app helps others “see” the world, Reuters via CNA, published 18 August 2026.