[ui5-wizard-tab]: accessibility issue with listitem of wizard-tab not being direct child of parent with list role

[OvcharovGeorgi]

Bug Description

When using Chrome addon Access Assistant to test the component, an accessibility error is shown which shows that the listitem is not in a list. While there is a div with a role of list and a div with role of listitem, in between there is the ui5-wizard-tab component that breaks the direct chain of parent-child, thus violating accessibility practices.

Affected Component

ui5-wizard

Expected Behaviour

Follow accessibility conventions - Ensure list items are found in a list container. The listitem child should be a direct child of the list.

Isolated Example

No response

Steps to Reproduce

1. Open an example of a ui5-wizard
2. Run Accessibility Assistant

Log Output, Stack Trace or Screenshots

Priority

Medium

UI5 Web Components Version

2.6.2

Browser

Chrome

Operating System

No response

Additional Context

Run on server different from https://sap.github.io/ as the addon does not catch on

Organization

SAP / UDEx components team

Declaration

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

[IlianaB]

Hello @SAP/ui5-webcomponents-topic-rl , please have a look at this accessibility issue regarding Wizard component.
Access Assistant tool reports a problem: "Ensure list items are found in a list container", as there is an intermediate ui5-wizard-step element between the div with role="list" and divs with role="listitem".

[elenastoyanovaa]

Hello,

We have analyzed your report and discussed with the accessibility experts. Our opinion is that rather this is a limitation of the automation tool and not a issue of the component.
We have analyzed the computed accessibility tree:

Which is calculated correctly and you can check it yourself in Chrome. Also the speech output is correct as well, which also tells us that the Screen Reader Software supports this as valid.

Another point is that the same issue is not reported by axe-core, another common tool for accessibility testing, which is widely used in WEB.

Another step further is that if we use ul -> li in the same way, this should be correct as well, following the WEB standard for web components and shadow dom. Testing with SR and the computed accessibility tree points to the fact that this in fact should be correct as well. Unfortunately, this case is also a limitation for the automation tools and it is reported for axe-core:
https://stackoverflow.com/questions/78129019/can-you-have-an-li-in-a-autonomous-custom-element-with-the-parent-ul-not
dequelabs/axe-core#4121
dequelabs/axe-core#4259

So basically this is not an issue for us. What we did apart from analyzing is that we reported internally the issue (both cases with div role=list -> div role=listitem and ul -> li) to Level Access, which are the owners of the Access Assistant. Hopefully this will be fixed and supported soon in a timely matter.

Thank you for reporting this!

Kind Regards,
Elena