Hello,

Thank you for your report and information on the focus path. 

By design, the implementation that comes from the Dialog component aims to trap the focus only when the tab sequence has not been interrupted by an element that has tabindex > 0. Therefore, it depends on the normal flow of the focus. If it were to completely discard the focus path, this would mean that on each Tab keystroke, we should traverse the whole HTML dom tree and decide which element should receive focus. This is error-prone and might lead to unexpected tab focus flow of the page. 

Having elements with tabindex > 0 is generally a corner case and solves a very specific task (usually business-specific). Such scenarios require tailor-made solutions on Tab key trap. 

What I recommend is that you handle the VisibleChanged event and attach a custom keydown handler of yours. This should happen by invoking a JavaScript function that uses the addEventListener() method to attach the event to the dialog's element. More specifically, when attaching the event through addEventListener(), you should specify the useCapture property. This ensures that your custom keydown event will be invoked before the default event that comes from the Dialog. Use stopImmediatePropagation() if you want to stop the default event handler from being triggered. 

An alternative is to track when the dialog is visible and ensure that the elements on the page have their tabindex attributes set to either 0 or -1 so that they do not interfere with the tab flow of the elements inside the dialog. 

Best regards,
Tsvetomir
Progress Telerik