By 2021, digital accessibility was gradually moving beyond the realm of expert discussion. For teams developing enterprise services, it is becoming not only a matter of standards compliance but also an essential part of the user experience.
A person may be able to see a screen yet struggle to distinguish small elements, lose context when zooming in on an interface, become fatigued by visual clutter, or be unable to complete a work-related task efficiently.
In this area, the role of the QA engineer is particularly important. Quality assurance professionals evaluate a product not only by whether it performs its intended function, but also by whether a person can confidently complete the entire user journey.
Daniil Khudenko works with digital services whose interfaces involve making selections, entering information, confirming actions, tracking statuses, and processing payments. For products like these, accessibility is part of reliability: if a user cannot identify an active element, read an error message, or understand the next step, the service may technically remain functional while effectively becoming inaccessible.
In this interview, Daniil explains why accessibility for people with low vision cannot be reduced to checking contrast ratios and font sizes, how QA can uncover problems that remain invisible during a conventional interface review, and why a mature approach to quality begins not immediately before release, but with an understanding of real user scenarios.
1. Daniil, a company may comply with formal accessibility requirements while users continue to experience difficulties: they may be unable to distinguish interface elements, lose context, or become fatigued by an overloaded screen. In your view, where is the line between “an interface that complies with standards” and “an interface that is genuinely accessible”?
Daniil Khudenko:
For me, the line is crossed when formal compliance no longer corresponds to a person’s actual experience. An interface may produce no technical errors, open correctly, save data, and even meet basic accessibility requirements, while a user with low vision still encounters serious difficulties. They may be unable to distinguish the boundary of an input field, confuse active and inactive elements, lose their bearings after zooming in, or fail to notice an important message.
At that point, the issue becomes a product-quality problem. From the system’s perspective, everything may be working correctly. From the user’s perspective, however, the service becomes unpredictable and exhausting. These are precisely the situations testing must identify, because accessibility is not merely about complying with a standard. It is about whether an interface remains understandable in real-world use.
This is particularly evident in digital services where people come not simply to view information, but to complete an important task: submit a document, check a status, find specific information, confirm an action, select a service, or complete a purchase. When the interface becomes an obstacle, the problem extends beyond a single screen. It affects the entire user journey and undermines trust in the service.
That is why I see accessibility as part of overall product quality, rather than as an additional check performed after development is complete.
The role of QA is to broaden the definition of quality itself. It is not enough to verify that a function works technically. We must also understand whether the service remains clear, manageable, and predictable for people with different levels of visual ability. In that sense, accessibility is not a separate branch of testing. It is a way of looking at the product more honestly—not only through the eyes of the development team, but through the reality of the user experience.
2. People with visual impairments interact with digital services in different ways. Some rely on screen magnification, others need stronger contrast, and others depend on convenient keyboard navigation. How can a head of testing bring these different situations together into a clear process, so that the team tests real user scenarios rather than an abstract concept of “accessibility”?
Daniil Khudenko:
I start not with a list of visual conditions, but with practical user scenarios. First, we need to understand which tasks are fundamental to the product and under what conditions users perform them. We can then apply several modes of interaction to those tasks: zooming the interface, adjusting contrast, navigating by keyboard, or working with limited visibility of certain elements. This produces not an abstract checklist, but a map of how a user moves through the system.
It is important not to attempt to simulate every possible condition. That would be neither possible nor necessary. The leader’s task is to identify several representative modes in which difficulties are most likely to arise. These may include small typography, dense tables, modal windows, visually similar buttons, or error messages that appear outside the user’s current field of attention. These areas can reveal a great deal about the overall condition of the interface.
In my experience, this approach enables the team to work with specific, practical cases. Instead of a vague instruction such as “test accessibility,” we define concrete scenarios: create a record at 200% zoom, identify an error in a form without using a mouse, or read an object’s status in a densely structured table.
These scenarios are also easier to explain to developers, designers, and managers, because everyone can see the connection between the test and the user’s task.
This model also makes the workload easier to manage. Accessibility stops being an undefined topic that is difficult to estimate or schedule. It becomes a set of testable scenarios that can be incorporated into the regular acceptance cycle and expanded as the product evolves.
3. A UX defect affecting a user with low vision may not be obvious to the team. The interface may look polished, yet remain difficult to use. What signs tell you that the problem lies specifically in the user experience, rather than only in the technical implementation?
Daniil Khudenko:
The first sign is that the user loses context. For example, a person opens a form and enlarges the screen, causing some prompts or error messages to move outside the visible area. Formally, all the elements are still present, but the connection between the user’s action and the resulting response has disappeared.
To the user, the interface becomes unpredictable: they click a button, something happens, but they do not understand exactly what occurred.
The second sign is that the visual hierarchy works only for someone viewing the screen under standard conditions. Color, size, spacing, thin lines, and subtle differences in shade are often used as the primary means of communicating meaning. For a person with low vision, these distinctions may be insufficient. The interface may still follow the correct business logic, but it no longer functions as a readable system of signals.
The third sign is that the user begins to “fight” the interface. Instead of simply completing an action, they are constantly reconstructing the context: trying to determine where the focus went, where an error appeared, which row corresponds to a particular button, or what changed after they clicked.
This is especially critical for users with low vision because some visual cues may be unavailable or difficult to distinguish. When a service forces people to continually second-guess themselves, the issue is no longer a minor inconvenience. It is a user-experience defect.
4. In projects where you are responsible for establishing QA processes, your role involves not only identifying defects but also defining how the team works. How do you incorporate UX accessibility into the process so that it does not remain the personal initiative of a single engineer?
Daniil Khudenko:
Ideally, UX accessibility should be addressed long before final testing. It should be reflected in the product architecture, the design system, component requirements, and user scenarios.
When a team understands in advance how forms, tables, modal windows, error messages, statuses, and navigation elements should behave when the screen is enlarged or the interface is operated by keyboard, accessibility becomes part of normal product design rather than a separate task before release.
In practice, however, the situation is often different. The product already exists, the interface is complex, there are many scenarios, and accessibility has previously been tested only in fragments.
In such cases, I begin by bringing structure to the process. First, I identify the key user scenarios: where a person completes an action, reads a status, selects an option, corrects an error, or returns to a previous step. I then identify the interface areas most likely to create problems, such as tables, forms, filters, modal windows, dense action panels, and long lists.
After that, testing becomes a reproducible process rather than the personal initiative of one engineer. For each critical scenario, the testing conditions are documented: zoom level, contrast settings, keyboard navigation, data state, and expected interface behavior.
These checks can be incorporated into regression testing, passed on to new team members, used during change acceptance, and gradually translated into standard requirements within the design system and product documentation.
For me, the key is a systematic approach. If accessibility was overlooked at the beginning, that does not mean the product cannot be brought to a more mature level. Progress simply needs to be guided not by a chaotic list of observations, but by a risk map: which scenarios are used most frequently, where a defect interferes most seriously with the user’s task, and which recurring components would produce the greatest benefit if improved.
That is how accessibility becomes part of quality management rather than an occasional check performed “when possible.”
5. When companies discuss accessibility, it is often framed as a matter of social responsibility. But people with low vision are not merely recipients of assistance. They are ordinary users, clients, customers, and employees. Why is it important for businesses to view accessibility in those terms?
Daniil Khudenko:
Because accessibility is not a charitable layer added on top of a product. It is the service’s ability to work for a broader audience.
People with low vision buy products, use transportation, complete official paperwork, work in enterprise systems, pay for services, compare providers, and make decisions just like everyone else. When an interface prevents them from doing these things independently, the company is effectively excluding a portion of its users from normal digital interaction.
For businesses, this is also a question of quality. An inaccessible interface can mean lost orders, additional support requests, abandoned transactions, form-entry errors, and declining trust in the service.
Sometimes the issue may appear minor: an unclear button, insufficient contrast, an overloaded table, or an error message that is difficult to notice. For the user, however, that issue may be enough to abandon the task or move to another service.
That is why I would not separate accessibility from product effectiveness. A good interface should be understandable not only to the “average” user under ideal conditions. It should remain clear when someone enlarges the screen, uses keyboard navigation, has difficulty distinguishing elements, or becomes fatigued more quickly by visual overload.
In this sense, accessibility is not a special accommodation for a small group. It is a way to make a product more resilient, more understandable, and commercially stronger.
6. Teams may also disagree about how tasks should be prioritized during a project. A defect may be critical from the user’s perspective but may not appear to be a release blocker from the business’s point of view. How do you approach such decisions?
Daniil Khudenko:
I try to move the discussion away from whether something is simply “important” or “unimportant” and toward the consequences of the defect.
When a defect prevents the user from completing a core task, it should be treated as serious even if the system does not technically crash. For example, if a person cannot determine which field in a form has been completed incorrectly, they will be unable to submit the information. That is not a cosmetic issue.
Priority also depends on the product context. The impact is different for a public informational page than it is for a work tool that someone uses for a substantial part of the day. In enterprise systems, even relatively small barriers in frequently repeated operations can lead to significant losses of time and an increase in errors.
That is why I always connect the defect to both the frequency of the scenario and the importance of the task.
When working with management, specific evidence is helpful: a recording of the user journey, clear reproduction steps, and a description of the settings being used. When it becomes clear that the user is not merely inconvenienced but is unable to proceed without a workaround, the priority becomes easier to understand.
In this sense, QA should bring evidence to the discussion, not emotion.
At the same time, I do not believe that every accessibility defect must stop a release. There needs to be a system of severity levels. Some problems can be addressed in the next iteration if they do not block essential actions.
However, that decision to defer a fix must be deliberate and documented. It should not happen simply because the team was unable to explain the problem clearly.
7. In 2021, accessibility is gradually becoming part of the enterprise-development agenda. What needs to change within product teams for UX accessibility testing for people with low vision to become a routine engineering practice rather than a rare exception?
Daniil Khudenko:
I believe several changes are necessary.
First, accessibility needs to be discussed in advance. When the team remembers it only during final testing, the QA department is placed in the position of delivering bad news immediately before release. That is ineffective.
When questions of readability, contrast, navigation, and interface behavior under magnification are discussed during the design and requirements stages, the necessary improvements become a natural part of development.
Second, foundational knowledge needs to be distributed across roles. Designers need to understand how visual hierarchy is perceived by people with reduced visual acuity. Developers need to know how to implement components so that they retain their meaning under different settings. QA professionals need to know how to test a scenario outside standard viewing conditions.
When this knowledge is concentrated in a single specialist, the process remains vulnerable.
Third, quality needs to be measured through task completion, not only through compliance with individual requirements. Standards are necessary, but products do not exist for the sake of a compliance report.
If a user with low vision can confidently complete a key journey, understand error messages, return to the correct screen, and finish the intended action, then the team is genuinely moving toward an accessible experience.
To me, that is the role of a software quality assurance expert: not simply to identify defects, but to help the team see the product more broadly.
Accessibility reveals how honestly we understand the word “quality.” If a product works only under ideal conditions, then we are seeing an incomplete picture. The role of QA is to make that picture more accurate.
The conversation with Daniil Khudenko demonstrates that UX accessibility for people with low vision is neither a narrow technical check nor a gesture of social courtesy. It is a way of understanding whether a digital service remains a clear, predictable, and independently usable tool outside an idealized scenario—when the screen is magnified, the visual hierarchy is perceived differently, and an error message or status update must be noticed without unnecessary strain.
In Khudenko’s approach, accessibility becomes part of the professional conversation about product quality. He treats it not as a collection of disconnected requirements, but as a system encompassing scenarios, data, components, priorities, repeatable checks, and clear criteria for the team.
This perspective is particularly important for services people use not out of casual interest, but to perform a specific action: purchase a product, arrange a service, check a status, complete a form, pay for an order, or carry out a work-related operation.
In 2021, as an increasing number of everyday processes move online, ignoring this dimension of quality is becoming more difficult. People with low vision are not an abstract “special audience.” They are clients, employees, customers, and participants in the same digital processes as everyone else.
Accessibility is therefore simultaneously a matter of personal independence, trust in a service, and the maturity of an engineering team. The role of the QA expert is to identify a barrier before it becomes part of someone else’s everyday life.
