[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

• 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: w3c/aria-practices#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

[yanaminkova]

Hello @GongRichard,

The outcome of the discussions was that we cannot offer a solution at the moment.

Referring to our central note: https://me.sap.com/notes/3260235, the component is to be considered conformant as per the definition of the W3C.

More specifically, the following sections:

3. Primary and Secondary Functions of ATs
   As per W3C definition, there needs to be one conforming version of a web page. SAP follows this recommendation by providing a code base that implements up-to-date accessibility standards (see point 1 of this section). Should ATs prove SAP’s code base viable through their Main Functionality, such as speech output, but render it invalid through a Secondary Means, such as go-to-functions, then the code base is to be considered conformant as per the definition of the W3C.

4. Fixing Issues in Secondary Functionalities of ATs
   Issues in Secondary Functionalities of ATs will be fixed only if they are reflected in both, the SAP codebase and the ATs' Primary Funtionality.

as well as the following:

2.5.3 - Label in Name
This Success Criterion requires that the text of the visible label is part of the (invisible) accessible name. It does not require that the accessible name is unique. Instead, it shows that the accessible name can be equal to the label, which in return does not need to be unique.

I will therefore close this case.
Thank you for understanding!

Kind regards,
Yana

[judith9209]

disagree in above explanation. The WCAG issue 2810 should not have been taken for this issue as an answer. It describes different topics. For this issue, the accessible name of a checkbox is "Multiple Selection mode" that does not match the visible name of a checkbox like "List Item 1".
You are referring to 2.5.3 - Label in Name that is full of quotes why this issue; even the naming of one single checkbox can be perceived as incorrect because visible text does not match accessible name:

https://www.w3.org/WAI/WCAG21/Understanding/label-in-name.html
"Label in Name (Level A)"
"The intent of this Success Criterion is to ensure that the words which visually label a component are also the words associated with the component programmatically. This helps ensure that people with disabilities can rely on visible labels as a means to interact with the components."
"Users typically have a much better experience if the words and characters in the visible label of a control match or are contained within the accessible name. "
"Where text labels exist and are properly linked to the user interface components through established authoring practices, the label and name will normally match. When they don't match, speech-input users who attempt to use the visible text label as a means of navigation or selection (e.g., "move to Password") will be unsuccessful. The speech-based navigation fails because the visible label spoken by the users does not match (or is not part of) the accessible name that is enabled as a speech-input command. In addition, when the accessible name is different from the visible label, it may function as a hidden command that can be accidentally activated by speech-input users."
"Mismatches between visible labels and programmatic names for controls are even more of an issue for speech-input and text-to-speech users who also have cognitive challenges."
https://www.w3.org/WAI/WCAG21/Techniques/general/G211
"Matching the accessible name to the visible label"
https://www.w3.org/WAI/WCAG21/Techniques/general/G208
"Including the text of the visible label as part of the accessible name"
"the text string that makes up the visible label must occur in its entirety in the accessible name. "

Regarding your point "assistive technologies (AT) are best suited to handle labeling in such cases/assistive technologies (AT) may autonomously handle the labeling of such cases".
Let's assume AT would already be able to concatenate the text right next to the label when ariaLabelledBy is present.
-> Than instead of the text "Multiple Selection mode", "Multiple Selection mode List Item 1" would be the accessible name. Why is it necessary to have a different accessible name than the display text? "Multiple Selection mode" is unnecessary announcement. Which value does it really bring? If AT provide the feature of auto labelling the text right next to it, than the accessible name would be still not proper, right?
-> Please read https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/#name_calculation
You are here in case 1, aria-labelledby is present; no further automatic name calculation happens. You would need to go into at least to case 4 that screen reader vendors would apply the name calculation for a child element you mentioned.

It looks like you had already issues by not providing ariaLabelledBy; therefore you worked on BCP issues linked to https://jira.tools.sap/browse/CPOUIFTEAMB-1566 https://git.wdf.sap.corp/c/openui5/+/4990603 . This fix was than just taken over to webcomponent.

[judith9209]

Feel free to have a look at the wcag discussion about this issue: w3c/wcag#4190