Accessibility Issue: Interactive controls must not be nested

Posted by: jacob.evans on 19 March 2024, 1:09 pm EST

  • Posted 19 March 2024, 1:09 pm EST - Updated 19 March 2024, 1:14 pm EST

    Hey,

    We are currently undertaking accessibility work, and I have encountered an issue with the Wijmo listbox. When running the Axe dev tools against it, it picks up an accessibility violation: Interactive controls must not be nested.

    The issue can be seen in this example https://jsfiddle.net/Wijmo5/j4te9fwp/3/.

    Is there any possibility this can be fixed? This implementation also suffers from the same issue raised here, with the list box being rendered outside of any landmark roles: https://developer.mescius.com/forums/wijmo/inputdatetime-rendering-outside-of-main-body

    Let me know if there is a way to resolve this currently or if you require any more information.

  • Posted 20 March 2024, 8:54 am EST

    Hi Jacob,

    We are currently investigating both of the issues you’ve reported and will provide an update soon. Thank you for your patience and understanding.

    Best regards.

  • Posted 20 March 2024, 9:44 am EST - Updated 20 March 2024, 9:49 am EST

    Hi Sonu,

    Thanks for the reply.

    Please note this issue is also present on the filter dropdown as part of the datagrid.

    I assume they are both using the same underlying listbox control

  • Posted 21 March 2024, 9:13 am EST

    Hi Jacob,

    I have escalated both this issue and your other accessibility concern with the InputDateTime control to the Development team. The internal tracking ID for this issue is WJM-33613. I have requested the Dev team to investigate both issues and provide a response as soon as possible. I will keep you updated and provide further information as soon as I receive any updates. I appreciate your patience.

    Regards

  • Posted 10 April 2024, 12:37 pm EST

    Hey, is there any update on this?

  • Posted 11 April 2024, 5:50 am EST

    Hi Jacob,

    Sorry, but there is currently no update on the issue. The problem is still under investigation by the development team. I have requested them to prioritize the issue and provide a resolution as soon as possible. I will keep you updated as soon as I hear back from them.

    I appreciate your patience.

    Regards

  • Posted 17 May 2024, 5:04 am EST

    Hi Sonu,

    Is there any update on this?

    Cheers,

    Jacob

  • Posted 20 May 2024, 12:15 am EST

    Hi Jacob,

    All of your reported accessibility issues are being reviewed. As mentioned in your other ticket, our Dev team is actively working on accessibility improvements for Wijmo controls. They are also investigating the use cases you reported and will consider incorporating them if feasible. Currently, there are no updates, but I will inform you as soon as I hear back from them.

    Thank you for your patience.

    Regards,

  • Posted 1 August 2024, 8:51 am EST

    Hi,

    Is there any further update on this issue (and others I have reported), or are they still under development.

  • Posted 2 August 2024, 7:59 am EST

    Hi Jacobs,

    I apologize for the inconvenience. The issue is still in development. I have requested an ETA for resolution and will let you know as soon as I receive a response.

    Regards

  • Posted 19 December 2024, 6:11 am EST - Updated 19 December 2024, 6:16 am EST

    Hi Jacob,

    As per the dev’s investigation, this is considered by design. Here is an explanation for that:

    Regarding “Interactive controls must not be nested”, as per my understanding, what axe-devTools is reporting is that even if tabIndex for the checkbox is set to “-1”, the assistive technologies will still focus on the checkbox. Since listBoxItem elements have the role attribute set to “option”, they are interactable for assistive technologies. However, the listBoxItem element also contains a checkbox, which is itself is an interactable element. Hence, the issue “Interactive controls must not be nested” is reported.

    As per the description of the issue under “Why it matters?”, it is mentioned that “Focusable elements with an interactive control ancestor (any element that accepts user input such as button or anchor elements) are not announced by screen readers and create an empty tab stop. That is, you could tab to the element but the screen reader will not announce its name, role, or state”. However, as the focus for FlexGridFilter is programmatically handled by Wijmo, the focus cannot be shifted to the checkbox present in a listBoxItem. If a user wants to interact with the checkbox using the keyboard, then the “Space” key should be used. Since the focus will not be shifted to the checkbox, the assistive technologies will also not be able to focus on the checkbox placed within the listBoxItem element. Therefore, it can be considered “by design.

    Regarding “All page content should be contained by one landmark”, it is not related to the FlexGridFilter. In this case, the customer can set the role attribute to “main” on the container of FlexGrid’s hostElement.

    Regards,

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels