Many people consider a Software application accessible simply because a blind person is able to use it. To me, that is only the starting point. The real questions are different: How comfortable is it to use? How much time does it take to complete a task? How many steps are required to achieve the desired result?
A piece of software may be technically accessible while still being cumbersome in everyday use. If completing a task forces me to interrupt my workflow, search for information, change the way I work, or follow an unnecessarily long sequence of actions, then something is still wrong.
Outline
- Beyond Technical Compliance
- The Flow of Thought and Cognitive Friction
- Sequential Perception vs. Spatial Vision
- The Math of Micro-Delays
- The Dual Perspective: Developer and User
- From Accessibility to Usability
- Where Accessibility Meets Usability
- Bibliographic notes
Beyond Technical Compliance
Throughout the development of Biblos, I have always tried to look beyond the mere functionality of individual features. My goal has been to create a tool that allows people to work naturally, without constantly having to adapt their workflow to the limitations of the software.
One thing I am certain of is that Biblos is not perfect. After many years of development, I have learned that consistency is one of the fundamental ingredients for keeping a project alive. Only through continuous improvement is it possible to keep pace with evolving technologies while continuing to meet the needs of the people who rely on the software.
The Flow of Thought and Cognitive Friction
At the age of thirteen, I intuitively understood that accessible software must preserve a person's flow of thought. The Computer should never become a barrier between an idea and its realization.
At the age of fifty-three, I have come to understand why. When people write and organize their work, their thinking follows a continuous path. Ideas emerge, connect with one another, change direction, and evolve. The software they use should support that process rather than interrupt it.
If every action requires waiting, if every command introduces a delay, if every operation forces the user to pause while the software responds, then something breaks.
This is especially evident for people who rely on assistive technology.
Sequential Perception vs. Spatial Vision
A sighted user receives a constant stream of visual information from the screen. They can instantly perceive the cursor's position, notice changes in graphical elements, or Monitor multiple events unfolding at the same time. Vision provides immediate, spatially distributed feedback.
A user who relies on a screen reader, by contrast, experiences the computer through a sequence in time. Every piece of information is delivered through speech synthesis or a refreshable Braille display. The software's response must therefore be accurate, consistent, and timely.
There is, however, another factor that is often overlooked: habit. Over time, users develop precise expectations about how a tool will behave. If a command normally produces a response in 100 milliseconds, even an occasional increase in response time may be enough to interrupt the continuity of the interaction. Even when the change is not consciously perceived, it can introduce subtle friction that diminishes the natural flow of the experience.
The quality of accessible software also depends on its ability to meet these expectations, because a smooth and predictable interaction fosters both confidence and familiarity.
While developing Biblos, I have always regarded responsiveness as a fundamental design principle. Software should never force users to wait for it. This philosophy is reflected in countless technical decisions that may appear minor: reducing startup time, eliminating unnecessary loading operations, keeping common tasks immediate whenever possible, and designing features that respond without introducing perceptible delays.
Sometimes, in software development, performance is treated as a secondary detail. If a feature “works”, the problem appears to be solved. However, for a tool used every day, for hours at a time, the difference between an immediate response and a delayed one becomes enormous.
The Math of Micro-Delays
Let us consider a concrete example: imagine a complex document whose creation and revision involve up to one million interactions with the software, including typing, navigation, selections, deletions, and various other operations. If we assume that each individual interaction has an average cost of 10 milliseconds, the total cost would be 10 million milliseconds, equivalent to approximately 167 minutes.
If the average cost of each interaction increased from 10 to 20 milliseconds, the total time required to perform the same operations would double, increasing from approximately 167 minutes to more than 333 minutes. A seemingly minor increase in the response time of a single software operation, when multiplied by hundreds of thousands or millions of interactions, can therefore become a significant slowdown in the user's daily experience.
The Dual Perspective: Developer and User
Biblos was born from a concrete need: to create a tool that would first and foremost allow me, as a blind person, to work with documents independently and efficiently, without having to constantly adapt my workflow to the limitations of technology.
As a daily user of assistive technologies, I have been able to observe software from a privileged perspective: that of the person who must rely on the program every day to accomplish real work.
The dual perspective of programmer and user inevitably led me to ask different questions. It was not enough to ask myself: “Is this feature available?” I also needed to ask:
- Can this feature be reached naturally?
- Does the software clearly communicate what is happening?
- Does the response time allow the user to maintain the rhythm of their work?
- Does this solution truly make the user's life easier?
These are questions that often do not emerge in conventional software development processes, because they require not only designing a feature, but experiencing the relationship between people and technology from the perspective of everyday interaction.
Perhaps the greatest challenge in developing accessible tools is creating technology that does not constantly demand the user's attention. The ideal software is the one that supports the work without becoming the focus of attention. It is present, but never intrusive. It helps, but does not interrupt.
When a person writes a document, prepares a project, or studies a text, their goal is to create something through the use of software. The role of technology is to remove the visible and invisible obstacles that stand between thought and the final result.
For this reason, in my view, accessibility cannot stop at technical compatibility. It must extend all the way to the User experience. A truly accessible program is one that allows people to work at the pace of their own ideas. This inevitably leads us into a field that I find even more fascinating: usability.
From Accessibility to Usability
So far, I have spoken about accessibility, but in reality I have gradually brought you, almost without explicitly saying so, into another domain: usability. I have discussed response times, continuity of thought, workflow fluidity, independence, simplicity of interaction, and the ability of software to support users without interrupting them. All of these concepts have appeared under the banner of accessibility, but they open the door to a broader and, in my opinion, essential horizon: usability.
Accessibility answers a fundamental question: can a person with a specific characteristic or need use this tool? This is an essential question. Without accessibility, many people are excluded from technology. But usability asks the next question, one that concerns everyone and goes even deeper:
Can a person use this tool in the best possible way?
A program can be accessible and allow users to achieve a result. Yet it can also be slow, complex, unintuitive, and filled with unnecessary steps. It may require constant attention just to understand what is happening, instead of allowing users to focus on the work they actually want to accomplish.
Let me give an illustrative example. Think about any kind of experience, digital or physical, in which we need to achieve a goal. The first question we naturally ask ourselves is: will it be easy?
Imagine using an Online service. We may spend an hour, or even longer, trying to achieve a result or find a piece of information. In the end, we realize that we have succeeded, but at what cost? The same task, if the service had been better designed, might have taken only five minutes.
I believe this example is significant because it describes a situation that anyone can encounter. When a service forces people to waste time and energy performing simple tasks, the problem is not accessibility, but a lack of usability. And usability is measured precisely in these terms: by how easily a person achieves their goal and by the absence of obstacles encountered along the way.
Are we beginning to understand the difference? Accessibility creates an opportunity. Usability determines the quality of that experience.
An accessible building is a building that a person can enter. A usable building is one where that person can move around easily, find their way, locate what they need, and experience the space naturally.
The same principle applies to software. Accessibility answers the question: “Can I do it?” Usability answers the question: “How easy is it to do it?”
This is why, throughout the development of Biblos, I have never considered accessibility as the final destination, but rather as the starting point of my work. The real challenge is not simply making a feature available, but making it natural to use. It is not only about enabling an action, but ensuring that the action can take place without interrupting the user's reasoning process and personal workflow.
Where Accessibility Meets Usability
During the development of Biblos, I am often guided by a thought from Antoine de Saint-Exupéry:
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
When accessible software allows people to achieve their goals while removing every unnecessary obstacle along the way, accessibility and usability have finally come together. When software follows the way people think and work, technology stops being merely a tool to command and becomes an environment in which people can work naturally.
That is the precise moment when we can focus on what we want to accomplish, leaving technology with the task of supporting us without standing in our way.
Bibliographic notes
- Steve Krug, Don't Make Me Think (2014)
Krug's central principle of usability is based on reducing cognitive load: an interface should be transparent and immediate, allowing users to complete their tasks without having to think about how the tool itself works. - Jakob Nielsen, Usability Engineering* (1993)
Nielsen analyzes interface response time limits, highlighting how delays exceeding 100 milliseconds can interrupt the perception of immediate causality and disrupt the continuity of everyday workflows. - Donald A. Norman, The Design of Everyday Things (2013)
Norman distinguishes formal accessibility from actual usability, arguing that the best design is one that removes every form of interaction friction, making technology a natural extension of human intention.
Giuseppe Di Grande is a software developer, accessibility expert, and the creator of Biblos, a specialized Word processor for Braille printing and tactile graphics that is used internationally. Founder and administrator of Iblaris, he has been developing assistive technologies for more than thirty years, combining the rigor of software architecture with his direct experience as a blind user.
This article was born from years of passion, experience, and a deep commitment to accessibility. If it helped you or inspired you, please consider sharing it by quoting a part and linking to the original page. It’s a simple way to show respect for the work behind it — and to help others discover it too.
Ìd love to hear from you — feel free to join the Biblos Facebook Group or follow us on the Biblos Telegram Channel. Let’s keep learning, sharing, and building a more accessible world together.