Your interface should work with one hand.

Imagine a repair checklist open on a phone beside a half-assembled lamp. One hand steadies the base. The other tries to tick off the step without opening the delete menu beside it.

There are probably more elegant ways to arrange the desk. The interface should not depend on finding one.

Software gets used with occupied hands, tired hands, and input methods the designer may not use. A control that works beautifully under a precise pointer can still ask too much of the person trying to finish the task.

For this imaginary checklist, I would start by separating the ordinary action from the destructive one. Give the completion control a generous target and enough space around it. Keep the visible label attached to the action, rather than making only a tiny icon tappable.

A bigger checkbox is a useful start. It is not proof that the application is accessible to everyone. Different people need different routes through the task.

Do not make dragging the only way

Suppose the checklist lets someone rearrange the repair steps. Dragging a row could be convenient with a mouse and awkward with one thumb. Provide another way to move it, such as choosing a destination or using explicit move controls.

That alternative matters for keyboard operation too. W3C’s keyboard guidance explains that functionality should be operable through a keyboard interface, with an exception for tasks whose underlying function depends on the movement path. Reordering checklist items is not freehand drawing; it should not require a drag gesture.

Keyboard access is not synonymous with a clever shortcut. A control someone can reach and activate through familiar navigation may be more useful than a hidden combination of keys. Avoid requiring several keys to be held together for an ordinary action when a simpler route is possible.

Keep that route discoverable. Someone should not need a help-page expedition to learn how to move a row without a pointer.

Make the current position obvious

A person navigating the checklist needs to know which control will respond next. W3C’s focus-visible guidance describes the need for a visible keyboard focus indicator. A clean design is not a good reason to remove it.

After marking a step complete, keep navigation predictable. If completed rows disappear, decide where focus goes and make the outcome understandable. Otherwise the person may perform an action successfully and then lose their place.

The same care belongs in a confirmation dialog. Closing it should return someone to a useful position, not to the beginning of a long page. Help text should remain available without requiring hover or a precisely held gesture.

Try the whole checklist with a keyboard. Then try the phone version while keeping one hand away from the screen. Those checks can reveal problems; they are not a substitute for broader accessibility evaluation or feedback from people using assistive technology.

A small tool should be ready for an ordinary, imperfect setting. Someone repairing a lamp ought to be able to finish a step without putting the lamp down merely to negotiate with its checkbox.