Diaphone started with a personal reason.
In 2019, one of our founders became a parent. His son was born with a genetic condition. The primary effect is total blindness. That fact reshaped the next several years of his life in ways he could not have anticipated, and it is where this story begins.
The years that followed were a long process of adjustment. Learning about the condition, about assistive technology, about how much of the world is built assuming everyone can see it. His son adapted in ways that continue to amaze. Our founder adapted more slowly.
His son is six now. Somewhere in the last couple of years, the way our founder looked at the world had quietly shifted. A website with buttons that have no labels. An app a screen reader cannot navigate. A form that traps a keyboard user and offers no way out. He had always known that accessibility was something teams were supposed to care about. He knew about screen readers in the abstract. What he had never looked closely at was what WCAG accessibility guidelines actually required, or that legislation like AODA existed in Canada to give those requirements legal teeth. In practice it sat the way most things in that category do: a compliance checkbox, something the legal team worried about, a WCAG compliance ticket in the backlog that never moved. It looked different once there was a real reason to pay attention.
The scale of it was what surprised him most. Not a few bad examples at the fringes of the web. The norm. Study after study puts the failure rate for basic automated accessibility checks above 90% of websites. These are not obscure edge cases. They are the fundamentals: can a screen reader read your page, can a keyboard user get through your checkout flow, does your button have a name, does your text meet basic colour contrast requirements. Most sites fail these. Most teams find out from the wrong source, and too late.
He started thinking about what could actually be done. His background was not in accessibility auditing or assistive technology. It was in infrastructure and DevOps, in monitoring systems and continuous feedback loops. And the longer he looked at the problem, the more it looked like a process failure rather than a knowledge one. Most developers know what alt text is and have a general sense of what WCAG requires. What most teams lack is a system that tells them when something regresses. No alert when a new deploy breaks a form label. No report ready when a client asks about their AODA filing deadline.
That is the gap Diaphone is built to close.
Automated scanning is not a complete solution and we will say so plainly. It catches around 30 to 40 percent of accessibility issues and it does not replace a qualified human auditor. But it catches the most common failures consistently, across every page, on every deploy cycle. That kind of coverage, running without anyone having to remember to run it, is what most teams do not have.
His son is going to use the web. He will try to buy things, access information, apply for jobs, and navigate systems that were mostly built without him in mind. We cannot fix all of that. But we can make it a little easier for the people building those systems to know when something is broken.
That is why Diaphone exists.