[SF][A11y][List] Unique accessible names are not provided for checkboxes

[saorabhkr]

Describe the bug

For a List/Tree where we have MultiSelect enable we observed unique accessible names are not there for the checkboxes

Isolated Example

https://sap.github.io/ui5-webcomponents-react/iframe.html?args=mode:MultiSelect&id=data-display-list--default&viewMode=story

Reproduction steps

Go to List Page

Enable JAWS shortcuts keys Try accessing the checkboxes, and open JAWS shortcuts keys dialog will not have a unique name for checkboxes.

Expected Behaviour

For a List/Tree where we have MultiSelect enable all the checkboxes should have a unique names. a unique name

Screenshots or Videos

UI5 Web Components for React Version

v1.12.0

UI5 Web Components Version

v1.11.0

Browser

Chrome

Operating System

No response

Additional Context

No response

Relevant log output

No response

Declaration

• [X] I’m not disclosing any internal or sensitive information.

[MarcusNotheis]

Thanks for reporting! I'll forward this issue to our UI5 Web Components Colleagues as the affected component is developed in their repository.

[yanaminkova]

Hello @saorabhkr,

Thanks for reporting.

I am not sure that I fully understand the issue. In the example you have provided, the Checkboxes do have accessible-names, which are being announced by JAWS and also visible on the Virtual HTML Features Dialog, which screenshot you have also added in your message.

Could you please give a bit more information and steps for reproducing the reported problem so we could help you.

Thanks and Kind Regards, Yana

[saorabhkr]

Hello @saorabhkr,

Thanks for reporting.

I am not sure that I fully understand the issue. In the example you have provided, the Checkboxes do have accessible-names, which are being announced by JAWS and also visible on the Virtual HTML Features Dialog, which screenshot you have also added in your message.

Could you please give a bit more information and steps for reproducing the reported problem so we could help you.

Thanks and Kind Regards, Yana

Hello @yanaminkova,

Yes you are absolutely right, checkboxes have accessible-names but if try navigation with JAWS keyboard help it is printing the common name, it should be unique.

To open JAWS keyboard press ctrl+insert+x. From that window select checkbox and observe the output. Please do let me know If you need any further help.

More in detail: Please find the below detailed steps to check this issue:

1. On the JAWS.
2. Switch to JAWS Virtual PC Cursor mode using keyboard shortcut Insert+Z
3. Navigate within the Add Attributes dialog using Up/Down Arrow keys.
4. Use Insert+F3 to open the 'Virtual HTML Features' or JAWS keyboard shortcuts dialog. 
5. Activate 'Check Boxes List' to see the unique accessible names provided for checkboxes.  

Hope this helps.

Best Regards, Saorabh

[dobrinyonkov]

We've discussed this question with the central accessibility team and we await for their feedback. I am setting this one to blocked until we receive a response.

[GongRichard]

Hi @dobrinyonkov, What's the plan for this issue? We got a customer issue about this issue. Would you please fix it ASAP? Thanks, Richard

[dobrinyonkov]

Hi @GongRichard,

we've explored the possible solutions here:

1) fordward the accessible-name of the list item to the checkbox - as long as apps provide uniqe accessible names to the items, the checkboxes will also have such.

2) internally set the text content of the list items as label of the checkbox.

3) hide the checkboxes.

There isn't really a general recommendation from the ARIA specification about such pattern. We've submitted a question to the aria practices and patterns repository asking to comment on this.

Let me know if you have any thoughts on the above.

[dobrinyonkov]

Hi @GongRichard,

After thorough discussions with accessibility experts, we have reached a point that assistive technologies (AT) may autonomously handle the labeling of such cases, as they possess the required contextual understanding.



It needs to be clarified why the labelling in closed context should be handled by web authors or web control developers and not by the user agent or assistive technology (auto-labelling). Assistive technologies are very aware of the context they consume from platform accessibility trees and could provide in their speech output by extended element info triggered by a special key or in their virtual overview dialogs means to identify the very position of e.g. a checkbox in a list/table cell with row/col position and list/table header information.

The opposite would mean, to make the labels really globally unique each and every such control (graphics, inputs, links, buttons, etc.) must be additionally labelled with the list header (there could be multiple list on the screen), the list item info (index / row header) and the column info if we’re inside a table (index / column header). The screenreader output would be horror.


More information and further discussions can be tracked with this GitHub issue: https://github.com/w3c/aria-practices/issues/2810

Kind Regards, Dobrin

[dobrinyonkov]

After consulting with accessibility experts, we believe that assistive technologies (AT) are best suited to handle labeling in such cases, as they can provide contextual understanding autonomously. We feel this should be managed by the AT, not web authors or developers, to avoid overwhelming users with redundant information.

Best regards, Dobrin

[dobrinyonkov]

More discussion about this will take place next week, I will post updates after.

[GongRichard]

Hi @dobrinyonkov， Any progress about this issue? We have customer to complain this issue. Thanks, Richard