This issue has been created
There is 1 comment.
 
 
XWiki Platform / cid:jira-generated-image-avatar-ea55ffc4-3a80-47fc-a6c5-c2a624218385 XWIKI-24755 Open

XClass properties can only be reordered with a mouse in the class editor

 
View issue   ยท   Add comment
 

Issue created

 
cid:jira-generated-image-avatar-1a7190ed-6c28-4dcc-a116-0db18ab22def Charpentier Lucas created this issue on 28/Aug/26 11:29
 
Summary: XClass properties can only be reordered with a mouse in the class editor
Issue Type: cid:jira-generated-image-avatar-ea55ffc4-3a80-47fc-a6c5-c2a624218385 Bug
Affects Versions: 18.7.0-rc-1
Assignee: Unassigned
Components: Edit
Created: 28/Aug/26 11:29
Labels: wcag
Priority: cid:jira-generated-image-static-major-7b5a1519-f7f8-43a2-9eb8-cd35fa58d59b Major
Reporter: Charpentier Lucas
Description:

In the class editor, XClass properties are reordered by dragging them, and the property "Number" field, which is what actually stores the order, is hidden by the same code that sets the drag and drop up:

xwiki-platform-web-war/src/main/webapp/resources/js/xwiki/editors/dataeditors.js
makeSortable(element) {
  if (element.length > 0) {
    // Hide the property number, as ordering can be done by drag and drop
    element.find('.xproperty-content').each(function () {
      ...
      input.parent().hide();

The drag and drop itself is implemented with jQuery UI sortable(), which is pointer-only and has no keyboard support, and the move handle is a <span class="tool move">, which is not focusable either.
So hiding the "Number" field removed the only keyboard route to reordering, and there is now no way at all to change the order of the properties of a class without a mouse.

Steps to reproduce

  1. Go to a page holding an XClass, for instance XWiki.MyClass, and open the class editor (?editor=class).
  2. Add two or more properties.
  3. Using only the keyboard, try to change the order of the properties.

Expected: the properties can be reordered.
Actual: they cannot. Tab does not reach the move handle, and the "Number" field that would allow
setting the position is hidden.

 

This fails Success Criterion 2.1.1 Keyboard,
and also Success Criterion 2.5.7 Dragging Movements.

Note

The same pattern is missing in the object editor, where objects cannot be reordered at all, see
XWIKI-5671.

 
 

1 comment

 
cid:jira-generated-image-avatar-1a7190ed-6c28-4dcc-a116-0db18ab22def Charpentier Lucas on 28/Aug/26 11:29
 

Suggested fix

We already fixed the very same problem for the Live Data column headers in XWIKI-21009: the drag handle
there is a real <button>, arrow keys move the column, and the focus is restored on the handle after
the move, see keyboardDragNDrop() in
livedata-ui/src/components/layouts/table/LayoutTableHeaderNames.vue. The navigation tree offers a
second variant of the same idea, with Alt+Shift+Up/Down and a visible hint documenting the shortcut, see
the "Reorder tree nodes using the keyboard" block in XWiki.PinnedChildPagesUIX and
PanelsCode.NavigationConfigurationSheet.

Applying the Live Data approach here would mean:

  • turning the move handle into a focusable <button> with a proper accessible name, the
    class.moveProperty.handle.label translation is already there;
  • handling the up and down arrow keys on it to move the property, reusing the existing
    updateOrder() so that both paths converge on the same code;
  • restoring the focus on the handle after the move, and announcing the new position in a live region;
  • keeping the "Number" field hidden, since the order stays fully operable without it.