XWIKI-20757: Fix label association for Menu content field in edit mode

[Derawaze]

Jira URL

https://jira.xwiki.org/browse/XWIKI-20757

Changes

Description

• Fix an accessibility (axe-core) label rule violation on the Menu entry inline edit page, where the <textarea id="content"> had no associated <label> element.
• The violation occurred because <label for="Menu.MenuClass_0_content1"> pointed to an ID that does not exist in the DOM — the WYSIWYG service produces a <textarea> whose DOM id is derived from the name parameter (content) rather than the id parameter (Menu.MenuClass_0_content1).

Root Cause

1. ClassSheetGenerator.xml generates <label for="${doc.fullName}_0_$property.name"> for every property, including Content fields. For the Menu app this produces for="Menu.MenuClass_0_content1".

2. Content.xml (the custom displayer for Content fields) computes $id = "${prefix}${name}" correctly as Menu.MenuClass_0_content1, but the WYSIWYG service ($services.edit.syntaxContent.wysiwyg()) ignores the id parameter and uses the name parameter value (content) for the actual DOM id.

3. CKEditor then replaces #content with its own UI — #content becomes a loading placeholder that disappears after page load, while the real editor (#cke_content) is labeled by CKEditor's own child <label>.

4. Axe finds <label for="Menu.MenuClass_0_content1"> pointing to a non-existent element, and #content having no associated label.

Short-Term Fixes

Fix 1: Menu/MenuSheet.xml line 44 — Removed the for attribute from the "Menu Structure" label:

- <label#if ($xcontext.action=='edit') for='Menu.MenuClass_0_content1'#end>Menu Structure</label>
+ <label>Menu Structure</label>

Rationale: The #content element is a CKEditor loading placeholder, not the real editor. Pointing a to it is semantically incorrect. CKEditor provides its own label for the editor.

Fix 2: AppWithinMinutes/ClassSheetGenerator.xml line 52 — Skip generating the for attribute for properties that have a custom displayer:

- <label#if ($editing) for="${doc.fullName}_0_$property.name"#end>
+ <label#if ($editing && "$!property.customDisplay" == '') for="${doc.fullName}_0_$property.name"#end>

Rationale: Properties with custom displayers (like Content fields using Content.xml) control their own DOM output. ClassSheetGenerator cannot predict the correct for for these properties, so it should not generate one. The $!property.customDisplay check follows the same pattern already used for $!property.hint on line 55. For standard properties without custom displayers, behavior is unchanged.

Clarifications

• The same issue likely affects other AWM-generated applications that use Content fields (e.g., Movies, Contributors from Help). Fix 2 (ClassSheetGenerator) addresses those automatically.
• The Menu app's WebHome.xml is intentionally set to <hidden>false</hidden> and is listed in visibleTechnicalPages in the pom.xml. A local XAR plugin version may incorrectly flag this during -Pquality builds — this is a pre-existing build infrastructure issue, not related to these changes.

Long-Term Direction

1. WYSIWYG service: Should respect the id parameter for the textarea DOM id, so that ClassSheetGenerator's for attribute matches correctly.
2. CKEditor integration: Should update associated <label> elements' for attributes to point to the CKEditor container when replacing a textarea.
3. AWM framework: Could provide a mechanism for custom displayers to declare the correct for target to ClassSheetGenerator.

Screenshots & Video

N/A (accessibility fix, no visual UI change)

Executed Tests

• Built both changed modules successfully in the XWiki Docker build image (xwiki/build):
  • mvn clean install -f xwiki-platform-core/xwiki-platform-menu/xwiki-platform-menu-ui -Pquality -DskipTests — passed
  • mvn clean install -f xwiki-platform-core/xwiki-platform-appwithinminutes/xwiki-platform-appwithinminutes-ui -Pquality -DskipTests — passed
• The Menu integration test (MenuIT) could not run locally due to Docker-in-Docker networking limitations on Windows (Testcontainers' testcontainers/sshd container port forwarding fails). This is a local environment issue, not related to the changes. CI will run the integration test.

Expected merging strategy

• Prefers squash: Yes
• Backport on branches: None