Can staff move a job on your task board without dragging it?

Buy a reliable status change

Imagine a small Hong Kong repair workshop with a shared tablet at the counter. Its board separates jobs into Awaiting inspection, In repair and Ready for collection. Moving a card looks straightforward in a sales demonstration. The purchasing decision is whether staff can make that same change without holding a finger down and carrying the card across the screen. Ask for an additional control if dragging is currently the only route; keeping drag available can still suit staff who prefer it.

Use a fictional job for a desk fan when comparing proposals. Define the authorised operator, starting status and permitted destination before discussing animation or colours. Also decide whether position within a column means priority. A menu that changes status is incomplete if dragging additionally sets the repair queue order and there is no other way to change that order. This distinction keeps the request small while preserving the work staff actually need to do.

Use the benchmark precisely

W3C's explanation of WCAG 2.2 criterion 2.5.7, Level AA, requires a single-pointer alternative to authored dragging functionality. Keyboard access alone is insufficient. Exceptions cover essential dragging and unmodified user-agent functionality, such as browser scrolling. Essential means removing dragging fundamentally changes the function and no conforming alternative can achieve it. A familiar board interaction is not essential merely because the supplier designed it that way. Here WCAG is a design benchmark for the purchase, not an assertion of a blanket Hong Kong legal duty.

Choose controls that fit the board

For this workshop, request a tap on the job followed by a Move menu with named destinations. An editable status field in the job details is another practical option, provided staff can reach and save it using taps. Visible destination buttons may suit a board with few states, but become crowded as the workflow grows. If queue order matters, add Move up and Move down controls or a position selector. These are proposed design choices; the right choice depends on the board's permitted transitions and the space available on the actual tablet.

Keep business rules identical across the routes. If only a supervisor may reopen a completed job, the new menu must not bypass that restriction. Ask what happens when saving fails or another employee has already changed the job. The card should not quietly appear completed while the stored status remains unchanged. Agree a clear result message and a way to recover from a mistaken selection. These are workshop acceptance requirements, rather than additional claims about what the dragging criterion itself mandates.

Run two separate demonstrations

Have a counter employee perform the first demonstration on the intended tablet and browser, with the supplier observing. Do not connect a keyboard for this pass. Reset the fictional job before a second pass using only a keyboard; check that focus is visible and the operator can reach, operate and leave the controls. Repeat both passes with English and Traditional Chinese interface settings. Record the device, browser, application version and outcome so a later fix can be checked against the same conditions.

Send one bounded change request

Before approving the purchase or change, send the supplier the example above with your real status names and permission rules. Request a working demonstration and a price that includes both input routes, both languages and the agreed tests. If the current product cannot support the change, compare an editable job-details route with changing the board component. Choose based on demonstrated completion of the task and ongoing maintenance responsibility. A screenshot of a new menu is not enough to close the request.