WCAG "Form elements must have labels" warnings on Extension Support / xclass object edit forms

The accessibility validation run as part of org.xwiki.repository.test.docker.AllIT#validateAllFeatures reports critical WCAG 2.0 A violations ("Form elements must have labels", wcag2a/wcag412/section508.22.n) on several pages:

• Extension/Support/WebHome
• Extension/Support/Supporter/Supporter1/
• The Extension inline edit page (create/edit of a "Macro JAR extension")

Affected fields include ExtensionSupporterClass_0_name, ExtensionSupportPlanClass_0_name, and on the extension edit form: ExtensionClass_0_source, ExtensionClass_0_description, ExtensionClass_0_customInstallationOnly (checkbox), ExtensionClass_0_installation, and ExtensionDependencyClass_

{0,1}_optional/_exclusions.

None of these inputs/textareas have an associated <label> (no implicit/explicit label, no aria-label/aria-labelledby, no title), so screen reader users cannot determine the purpose of the field.

Root cause (confirmed by code investigation):

The <input>/<textarea> markup for xclass property "edit" widgets is built in Java, in PropertyClass subclasses under xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/objects/classes/, using org.apache.ecs.xhtml.* builders. None of these displayEdit() methods emit a <label> themselves - label association is left to the caller (the "Object editor" template flamingo/editobject.vm does wrap fields correctly with <label for="${class.name}${obj.number}${prop.name}">, matching the id built by displayEdit as prefix+name).

A previous fix (XWIKI-22580) added a fallback aria-label to some property types as a safety net when a field is rendered without that wrapping label (e.g. via $doc.display($propName, 'edit', $object) called directly from a class-specific sheet/template, as is the case for the Extension* classes here). That fallback was not applied consistently to every property type, which is exactly why some fields fail and others don't:

Has aria-label fallback (OK):
- StringClass.java:113-139 (line 132-133)
- BooleanClass.displaySelectEdit (BooleanClass.java:190-238, aria-label at 200-201)
- ListClass "input" branch (ListClass.java:804-825, aria-label at 822-823) and displaySelectEdit
- BooleanClass.displayRadioEdit and ListClass.displayRadioEdit wrap each option in a real <label for="...">, so these are fine too.

Missing aria-label / label (BUG - matches the reported violations):
- PropertyClass.java:282-299 (base/default displayEdit, bare <input type="text">)
- NumberClass.java:201-219 (bare <input type="text">) - likely cause of ExtensionDependencyClass_0_exclusions if that property is numeric, otherwise same gap applies to any Number property
- BooleanClass.displayCheckboxEdit (BooleanClass.java:302-318) - bare <input type="checkbox"> with an id but no label/aria-label - matches ExtensionCode.ExtensionClass_0_customInstallationOnly and ExtensionDependencyClass_{0,1}

_optional

• PasswordClass.java:125-143 (bare <input type="password">)
• TextAreaClass.java:434-474 - delegates to a pluggable Editor<SyntaxContent> component, passing only id/name in the parameters map (lines 442-445), no label/aria-label parameter passed through at all - matches ExtensionCode.ExtensionClass_0_source/description/installation
• DBListClass.java, DBTreeListClass.java, StaticListClass.java, LevelsClass.java, ComputedFieldClass.java should be checked for the same bare-input pattern if they override displayEdit/displaySelectEdit instead of inheriting ListClass's labelled versions.