Concerning XWIKI-24755, the properties of an XClass can only be reordered by dragging them. The drag handle is a <span>, so it is not focusable, and there is no other way to change the order.
This breaks two success criteria, and they do not have the same answer:
SC 2.1.1 Keyboard would be met by a focusable handle answering the arrow keys.
SC 2.5.7 Dragging Movements would not be met by that same handle. Its Understanding page states that a keyboard equivalent does not meet the criterion “unless that equivalent keyboard operation also provides controls that can be clicked or tapped with a pointer”.
Here it seems to me like we have enough space to add visible controls to the UI and provide the most accessible experience.
Proposal
Replace the drag handle of each property with a move up and a move down button. Each property row then carries three tools: delete, move up, move down.
Details
Clicking or pressing the up or down arrow key on one of the buttons moves the property by one position.
The buttons keeps the focus when moving around, and the new position is announced in a live region.
Drag and drop keeps working as it does today. Dragging a property has never been restricted to the handle: a property is draggable from anywhere in its block, its title included, and that stays true. What the handle provided was the hint that a property could be dragged at all, not the drag itself. The two buttons are the one place a drag cannot start, so that a click which drifts by a pixel stays a click.
Here are what it would look like for the actions of a property title, on a class holding three properties:
It is the only option that closes both criteria. An arrow-key handle would leave SC 2.5.7 open.
Move up / move down is a familiar pattern, and there’s enough space here to have it without losing clarity. I think it is worth it on a screen that is already tool-heavy.
Conclusion
Do you agree with two visible move buttons per row, rather than a keyboard-only handle?
Losing the handle also loses the only visual hint that a property can be dragged. Is that acceptable, now that the buttons make reordering visible?
I’ll close this topic in a week if it doesn’t spur a larger discussion. A proposed implementation is in PR #6267.
Thank you for your interest in the topic! I’m looking forward to your answers
Lucas C.
Though, it is unclear to me why keeping the drag button would hurt. Alternatively, wdyt of changing the cursor when hovering the properties (using cursor: grab; for instance) to communicate the fact that the element can be drag-and-dropped (and possibly make this a global accessibility good practice) ?
Byw I noticed while testing that only a very small part of the Live Data headers have a “grab” cursor, possibly a bug/regression to check.
It would not hurt accessibility to keep it, it is only a UI choice. Three reasons I would rather drop it:
The way it’s implemented right now, it would still need to be updated even if we left it in.
It suggests that dragging only works from there, which was never the case (we could also decide that it becomes the case and limit dragging to clicks starting on this handle)
The number of “buttons” per property would increase from 2 to 4, which means the change brings in even more noise in the UI.
That said, I am not strongly attached to removing it. If we prefer keeping a visible drag hint, I’ll make sure it’s invisible to AT for which it would be noise overwise.
I think it is the better answer to the hint problem than the handle is, since the cursor covers the whole area that actually accepts the drag instead of pointing at one 16x16 icon.
Good catch. I’ll try add an improvement to the consistency of this click listener in the solution for XWIKI-24755.
I’m not strongly against having the arrows instead of the drag & drop but the arrows will create friction if people want to move a property very far from when it was in a class with many properties.
Another solution could be to not have arrows at all and instead ask the new index where the property should be put.
Right now on my side I’m missing the actual UC why people are moving properties at all in an XClass.
I also think moving the buttons on the left would be clearer, when there are many properties it’s hard to know which button is linked to which property. Moving left is easier, and IMO replacing the drag icon with a more common one (like the 2x3 dots we see in a lot of apps nowadays) would convey the meaning clearer.
Worth noting that this reordering feature is not new, we’d need a vote if we want to fix the issue by disabling the feature (regression on feature).
An index input would also satisfy SC 2.5.7, so it is a legitimate alternative. I would still rather have the arrows mostly because an input would turn the common case (moving a property by one or a few positions) into a form to fill. This would also assume the user counts the position where they want it, which might not be that easy to do with the current UI (properties are not numbered).
from me
+1 x 4 for the grab cursor, so we’ll add it. The two move buttons are the one spot where a drag cannot start, we update the cursor everywhere else. I’ll make sure the zone to start the grab from is increased so that it controls alright.
I see the point, a control right before the name it acts on is easier to associate than one at the far end of the row. IMO it’s a good idea but its implementation would make the PR scope that much bigger. I’d leave it in a redesign / UI pass on the component.
I think it is the better answer to the hint problem than the handle is, since the cursor covers the whole area that actually accepts the drag instead of pointing at one 16x16 icon.
we see in a lot of apps nowadays) would convey the meaning clearer.