The width control looked direct. A customer could drag a visual edge and see the curtain change. In a defined task with twenty-four adult participants, nine could not complete width setup where the interaction depended on that dragging action. The review exposed a distinction between the product's underlying function and the input technique its designers had chosen. The person needed to specify a dimension; the software had made one gesture the practical route to doing so.
We funded ₹52 lakh for labelled numeric inputs and keyboard controls alongside the visual interaction. The intention was not to prohibit dragging or make every customer use the same method. It was to provide another usable route to the same action. In a later task with the same twenty-four participants, three could not complete the setup. That was an encouraging observation with important limits, including possible practice and order effects. It did not establish complete accessibility or isolate every reason for the change.
Separate the action from the way it is drawn
A visual metaphor can become so familiar to its builders that the team treats it as the function itself. Moving an edge on a screen feels like changing width, but the underlying product requirement is a dimension with a defined meaning. That requirement can be represented through a numeric input and keyboard-operable controls as well as a dragging interaction. The engineering review should ask which actions a person must complete and whether the available routes let them do so, rather than assume that the most attractive demonstration is sufficient.
The task did not require a freehand path. That mattered because the value was the resulting dimension, not the shape of a movement. General keyboard-accessibility guidance informed our thinking, while actual assessment still required qualified review of the implementation. This fictional case does not issue a legal conclusion or claim compliance with an entire standard. It describes an engineering decision to make a particular action operable beyond one pointer technique, with the resulting behaviour examined in the actual customer journey.
We did not infer a diagnosis or disability from a participant's difficulty. A task observation tells us what happened in that review, not a person's medical circumstances. The useful product question was why the interface made completion depend on the gesture and whether another route could preserve the intended action. Keeping the account focused on the interaction avoids turning participants into labels that the evidence does not support. It also helps the team discuss design responsibility without making the difficulty seem like a characteristic the customer must overcome alone.
Design colleagues valued the immediacy of the visual change. That value remained legitimate. Providing a keyboard route did not require pretending that dragging was always a poor interaction. The decision was to retain the visual option while removing its exclusive role in completing the task. Product discussions become more useful when they can preserve what works for some people and address what prevents others from acting, rather than frame the choice as loyalty to one input method or the rejection of another.
An alternative route must preserve the same meaning
A numeric input would not help if it set a different dimension from the visual control or left the preview and saved design inconsistent. The alternative needed to participate in the same product state. That requirement connected the usability work with our wider engineering attention to units and valid configuration. The interface could offer more than one route, but the customer should not unknowingly create different meanings merely by choosing a different way to perform the action.
Labels also mattered because a number needs context. The person should understand which width is being changed and the unit in which it is expressed. The programme did not turn the software into a certification of the physical measurement; technical-design and actual measurement responsibilities remained distinct. The engineering task was to make the specified value understandable and consistent through the product journey. A successful keyboard event by itself would not establish that the customer had completed the intended action correctly.
The ₹52 lakh allocation supported the change and its assessment. It was not a price for universal accessibility or proof that every user could now complete every task. Funding made work possible; evidence still had to show what the resulting interface allowed in the reviewed context. A CTO should keep that distinction visible when reporting progress. Otherwise an organisation can replace one oversimplification—that an attractive dragging control is enough—with another—that adding an input field completes the accessibility question for the whole product.
Discoverability and continuity also belong in the review. A keyboard route that exists but cannot be found or understood may not provide the practical alternative the team intends. The evaluation should follow the actual sequence, including how the person reaches the control and how the resulting value is reflected. This case does not prescribe every technical detail of that assessment. It explains why the action must remain coherent across its available routes and why qualified review should examine the implementation rather than accept a feature checklist as the whole result.
An encouraging review is not complete certification
Nine participants initially could not complete the specified setup; three of the same twenty-four could not complete it later. Six fewer observed failures is a clear description of that comparison. It is not a controlled estimate of the change's effect because participants had already encountered the task and the order was not neutralised. We retained that limitation rather than turn a useful review into stronger causal evidence. The observation could justify continued work without being presented as a universal result for all customers or devices.
The remaining three failures mattered. A product team can become so relieved by an improved result that it treats the unresolved experience as a small residual rather than further work to understand. I wanted the account to preserve both the progress and the unfinished question. Qualified accessibility assessment also extends beyond this single width task. The programme did not establish every assistive-technology outcome, every page's operability or complete conformance. Those claims would require their own appropriate evidence and scope.
For directors and product leaders, the transferable question is whether the customer can perform the underlying action through the routes the service needs to support. The answer should retain the implementation, reviewed task and limitations of the evidence. A preferred gesture may remain a valuable option without being a necessary condition of participation. Engineering becomes more credible when it can explain that distinction, show what changed and keep the unresolved experience visible after an encouraging demonstration or usability result.