The alternative path must match the main path's capabilities

What it is

Move-up / move-down and a file picker can both be present and still be a shrunken road: dragging can insert at any slot, take many files, take folders, cancel in flight; the click path can only pin to top, only take one file, cannot choose items outside a type. Capability equivalence requires the alternative to do what the main path does, not “there is a button, so there is an alternative”.

Equivalence compares the set of results that can be completed, not whether the two paths look the same, and not whether they are equally easy to find — findability belongs with path-gesture alternatives. The only question here: if dragging can, can clicking.

Why it happens

Products often implement dragging as the full function and the alternative as an emergency hatch: reorder gets pin-to-top, upload gets single file, a board allows drop only at the end of a column, not insertion inside it. Mechanically those are two task graphs with different nodes. People gated onto the click path are not getting the same product. Equivalence aligns the graphs: reachable positions, accepted files, moments when cancel is possible, batch or not.

Another shrinkage is permission and state: dragging can overwrite an existing file; the picker is silently “create only”. Dragging can drop a card into a collapsed column (the column expands); the button path cannot see that column. Those are not the wrong widget type. They are extra edges on the main path that never appear on the alternative.

Studying it

List the main path’s capabilities first (position, batch, types, cancel, cross-container). Tick them on the alternative one by one. Each miss is a capability gap; do not fold them into “mostly works”.

Use the same materials: the same file set, the same move from index 5 to index 2. Success, failure messages and post-state should match on both paths. If the alternative is “email an admin”, record inequivalence; do not count a human fallback as a path.

Where it stops holding

Do not force equivalence that physics refuses: dropping ten files at once into a zone, while a system picker caps how many can be chosen in one dialogue — state the cap and allow repeated chooses to reach the same batch, rather than removing batch from the product. In live collaboration, the click path must be able to issue commands on the same object someone else is dragging, or “equivalent” only holds in a solo session. Guest accounts deliberately on a simplified mode should be compared to that mode’s actual main path, not to the internal full product.

Applying it

• Against every thing dragging can do, check move-up / down, the position field and the file picker: position set, multi-select, types, cancel, cross-container.
• Close gaps on the alternative. Do not re-gate capability behind “advanced features require mouse dragging”.
• How to check: list three things only dragging can do today (ten files at once, insert mid-list, drop mid-column) and do the same three on the click path. One miss is inequivalent capability.

Related

• Same group: J3.07.1 Reordering needs move-up/move-down or a position field · J3.07.2 Drag-and-drop upload needs a file picker
• Nearby: J3.05 Single-pointer alternatives · J3.11 Path-based gesture alternatives · H8.03 Drag-and-drop reordering
• Search terms: equivalent alternative · capability parity · degraded drag fallback