Shtilianova
commented
4 years ago Hello @mkueng1 , Thank you for sharing. I've created an internal incident 2080055762. The status of the issue will be updated here in GitHub. Regards, Diana
Closed mkueng1 closed 3 years ago
Shtilianova
commented
4 years ago Hello @mkueng1 , Thank you for sharing. I've created an internal incident 2080055762. The status of the issue will be updated here in GitHub. Regards, Diana
Thodd
commented
4 years ago Hi @mkueng1,
sorry to say this, but currently we don't have any plans on further investing into the blocking of controls. The blocking mechanism has some major issues concerning keyboard navigation and screen reader support. This is mainly a problem inside list controls, as the mechanism for handling the focusing is not valid inside ol/ul/li elements. The same is true for all controls using the ItemNavigation. We yet have to find a way to make the behavior consistent and reliable. However as mentioned, we don't have any plans in the near future to do so.
However if you are aware of these issues and don't expect your users/customers to need these accessibility features, you might think about living with the drawbacks.
Additionally we might ask @aborjinik for some input on the enabling of List elements. He might be able to give you some more information on that topic.
BR, th
mkueng1
commented
4 years ago Thanks for your feedback. The current behavior is totally fine as in my usecase the accessibilty drawbacks are not relevant. But using a property/mechanism which is marked as deprecated leaves a bit a bad feeling that it might get removed in a future version.
ecker
commented
3 years ago Hi @mkueng1, thanks again for your input. We understand the difficulties in some scenarios to fulfill all expectations for blocked handling and thorough accessibility. As had been explained, the given functionality can not always cover both. But good to hear that with loosening the a11y aspect you could achieve the desired result. As we don't have specific plans to further address the topic, we'll close this issue. Thanks + BR, Andreas
OpenUI5 version: 1.69+
Depending on your strategy this is a consulting or feature request issue. With version 1.69 the blocked property of sap.ui.core.Control has been marked deprecated due to accessibility reasons with the example of a list control. I'm missing an explanation what your strategy or other solution is. To be more concrete I have the need to disable a list or tree entry as long as some asynchronous server side logic is running. Are you introducing the enabled property on list/tree items in a way that a user can navigate over these entries without being able to select or trigger press or tap? Or is it totally fine to continue using the blocked property but being aware of the accessibility drawbacks?