XWIKI-19723: Navigation panel not accessible using a screen reader #3789
Conversation
* Added a `sr-only` description next to every tree AFAIK. This works for the navigation panel. * Added a default id for document trees * Added a translation key to contain the tree technical description.
| @@ -37,6 +37,9 @@ | |||
|
|
|||
| #macro (tree $options) | |||
| <div #treeAttributes($options)></div> | |||
| <span id="xtree#if($!{macro.options.id})-$!{macro.options.id}#{end}-description" class="sr-only"> | |||
| $services.localization.render('tree.macro.description') | |||
There was a problem hiding this comment.
| $services.localization.render('tree.macro.description') | |
| $escapetool.xml($services.localization.render('tree.macro.description')) |
| @@ -28,6 +28,7 @@ | |||
| 'filterByClass': '', | |||
| 'filterHiddenDocuments': true, | |||
| 'hierarchyMode': 'reference', | |||
| 'id': 'document', | |||
There was a problem hiding this comment.
I don't think this is the right place. The comment above says:
Configuration options for the Document Tree Source (that is used to retrieve the tree nodes).
We don't need the id to retrieve the tree nodes. The proper place is rather https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-tree/xwiki-platform-tree-war/src/main/webapp/templates/tree_macros.vm#L20 (that's where we set the default CSS class for instance).
As for the default id value, since we can't easily have a counter, I think we can use a random value. Here's an example https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-ckeditor/xwiki-platform-ckeditor-ui/src/main/resources/CKEditor/FileUploader.xml#L88 (timestamp + small random). I'd go with:
'id': "xtree-${datetool.date.time}-${mathtool.random(100, 1000)}",
| @@ -37,6 +37,9 @@ | |||
|
|
|||
| #macro (tree $options) | |||
| <div #treeAttributes($options)></div> | |||
| <span id="xtree#if($!{macro.options.id})-$!{macro.options.id}#{end}-description" class="sr-only"> | |||
There was a problem hiding this comment.
I don't think we should force an ID prefix. The default ID can have a prefix (see my other comment), but if the user specifies an ID, we should use it as is, i.e. we should only add the -description suffix.
Jira URL
https://jira.xwiki.org/browse/XWIKI-19723
Changes
Description
sr-onlydescription next to every tree AFAIK. This works for the navigation panel.Clarifications
instance_counterto generate those, but unfortunately it's not possible easily, and afaics any solution would have to be a bit hacky. Setting up our own velocity templating counter does not work since we load thistree.vmscript multiple times. It's technically bad to have multiple items with the same ID, however here it's for literally the same item/content, so it doesn't matter much (only the DOM position changes). Thanks to the resilience of web browsers and NVDA, we can see that everything still works correctly :)Screenshots & Video
Here are some demos I took with Chrome 131, NVDA and some XWiki 17.0.0 snapshot run locally.
Before the changes
https://github.com/user-attachments/assets/8016dc85-289f-417f-95d9-ff9a4d9501c7
We can see that the state of the tree is properly conveyed. However when the user arrives on it, nothing is said about how to operate it.
https://github.com/user-attachments/assets/5afb6262-3a5d-4c8b-820e-5cf0b20b9e09
Now, right when the user tabs to the tree, info about how to handle it is read out. Note that this info is read again when the user clicks on a
X morelink that reloads the whole tree. It could be a small annoyance but the benefits far outweight this drawback.Executed Tests
First, I successfully rebuilt all of the module affected by some changes:
mvn clean install -f xwiki-platform-core/xwiki-platform-tree/xwiki-platform-tree-macro ;mvn clean install -f xwiki-platform-core/xwiki-platform-tree/xwiki-platform-tree-war; mvn clean install -f xwiki-platform-core/xwiki-platform-index/xwiki-platform-index-tree/xwiki-platform-index-tree-macro. I went through theTreeElementBaseElement for docker tests, and it seems like the changes brought do not impact any xpath or query used in there. I then ran the tests on the wholexwiki-platform-indexmodule withmvn clean install -f xwiki-platform-core/xwiki-platform-index/xwiki-platform-index-test/xwiki-platform-index-test-docker -Dxwiki.test.ui.wcag=true. The tests passed properly and no WCAG failure was found. They extensively use theTreeElementand child classes.Expected merging strategy