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:
  • 15.10.x

[manuelleduc]

Does having an aria-label only apply to PropertyClass and StringClass only?
If we provide a default generic text alternative, it is probably better if we try to cover all cases.

[Sereza7]

Before reaching this solution, I tried to provide a generic fix for all Property types. However, the displayEdit function is overridden for a lot of object classes. This solution only fix String properties, but a similar solution could be used to provide text alternatives for the inputs of other property types.

Since there's no straightforward way to generalize this without updating all of the classes implementations for displayEdit, I don't think I want to merge it all at once.

These changes have a wide impact, so I'd rather keep them as minimal as necessary to avoid breaking things. See for example the number of test updates needed just for what was done until now.

Moreover it doesn't seem to me like it's needed for other property types. This might already be too generalized, in practice I only need this change to the displayEdit function for

xwiki-platform/xwiki-platform-core/xwiki-platform-release/xwiki-platform-release-ui/src/main/resources/ReleaseCode/ReleaseSheet.xml

Lines 53 to 63 in e5357c3

	#if ($xcontext.action == "edit" || $xcontext.action == "inline")
	$doc.use("ReleaseCode.ReleaseClass")
	Version: $doc.display("version")
	Release Managers: $doc.display("releaseManagers")
	Release Date: $doc.display("releaseDate")
	#else
	## Note: We use the include macro below to circumvent the "nested script" execution issue...
	{{include reference="ReleaseCode.ReleaseSheetHeader"/}}
	{{include reference=""/}}
	#end

. I could probably just have hardcoded a text alternative in this form sheet.

WDYT?

[manuelleduc]

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.

@Sereza7 you are probably missing a re-build of the distribution.

1. build the impacted xwiki-platform-core modules
2. build distribution again mvn clean install -f xwiki-platform-distribution (there is way to be more accurate, but this will do)
3. run the functional tests

Let me know if this lead to better results.

Also, you can check if the server produced by the test contains the right version of displayer_date.vm

[Sereza7]

Thanks for the help! After building the distribution again it used the right version in the tests.
There is no longer any WCAG failure in this test module :)

[manuelleduc]

LGTM, thanks!