XWIKI-22580: New release input fields have no text alternative

[Sereza7]

Jira URL

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

Changes

Description

• Added a default aria-label for StringProperties editDisplay.
• Added a default aria-label for Properties in the custom edition context.
• Used this context variable to fill up an aria-label for the date fields custom display.

Clarifications

• In the displayEdit test from StringClassTest, somehow this change also changed the order of other parameters. I modified it to match the new result, but I have no idea why this changed and how however this is stable across runs...
• Before reaching this solution, I tried to provide a generic fix for all Property types. However, the displayEdit function is overridden for the type which interests us (and many other interesting types). This solution only fix String properties, but a similar solution could be used to provide text alternatives for the inputs of other property types.
• There's multiple ways to label such an input. I decided to use aria-label:
  • PROS:
  • it's a fallback that'll only be considered after all more conventional ways to label an input (implicit or explicit labelling). It does not take precedence over other ways to label the input that have already been set up (which are surely more specific and better).
  • it does not change the structure of the output. The impacts on visuals and user customizations will be naught. Very good solution for backwards' compatibility.
  • CONS:
  • It's not standard HTML, we rely on ARIA. Some media might not make full use of the info we provide in this attribute. Minor con since this is a feature primarily implemented for assistive technologies, and ATs should implement ARIA.

Screenshots & Video

After the PR, we can see that both of the fields are labelled in a generic but correct way.

A test with axe devtool does not find any warning on this page. Before the changes it would have found two missing label.

Executed Tests

Successfully built oldcore with mvn clean install -f xwiki-platform-core/xwiki-platform-oldcore -Pquality After building the other changes with mvn clean install -f xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-templates, I ran the test that sent a WCAG warning on CI with mvn clean install -f xwiki-platform-core/xwiki-platform-release/xwiki-platform-release-test/xwiki-platform-release-test-docker -Pdocker -Dxwiki.test.ui.wcag=true. It returned only the warning for the date field (less than the two warnings from before). I do not understand why this automated test still warns about the date field. Manual tests on a local instance with updated StringClass.class, PropertyClass.class and displayer_date.vm showed that this date input warning is solved.
If this PR gets merged, I'll keep an eye on the CI tests to see how the results evolve. Hopefully it was just a test setup mistake from my end and this PR solves the ticket completely. If not, I'll try to figure out what's happening in the test suite and provide a patch to correct this test.

Expected merging strategy

• Prefers squash: Yes
• Backport on branches:
  • 16.4.x
  • 15.10.x