When building dynamic interfaces that update portion of a web page, managing focus is of fundamental importance for keyboard users and assistive technologies users.
The current Comments table in WordPress is not the best example, because it lacks some of the features implemented in other tables. I'll refer to the Posts list table for some examples of the interaction model that should be replicated.
go in the WordPress Posts list table
using the keyboard, focus on a "Quick Edit" row-action link
press Enter, the quick edit "form" opens
notice focus is programmatically moved to the first focusable element in the form
press Escape, or the Cancel/Update buttons (you can also mouse-click to save time)
the quick edit form closes
notice how focus is programmatically moved back to the control that opened the form
This is just an example, there are other cases where focus management will be necessary. From an accessibility perspective, it's a fundamental feature to avoid focus losses. When a focus loss happens, in the best scenario modern browsers are smart enough to try to keep focus in place and start again the tabbing sequence from a surrounding focusable element. In the worst scenario, browsers may completely be unable to do that and fallback focus to the document root. In this case, keyboard users, including screen reader users, would be forced to start navigating content from scratch: one of the worst thing can happen.
Worth noting this browsers "smart" behaviour has historically been introduced at different times. Firefox has this feature since years. Chrome starting from version 50. Safari starting from version 10. Internet Explorer 11 doesn't have this smart behavior and will always lose focus.
I understand in a React world implementing a focus management tool is not easy. There's the need to access the DOM and so some simple DOM manipulation. However, I'm hopeful and confident a smart solution can be found. As a reference, there's been some discussion on Slack around the same issue for Gutenberg, see even if the ongoing experimentation linked there is more about "constraining tab focus", it could be an example of how to get to the DOM in an "isolated" manner.
When building dynamic interfaces that update portion of a web page, managing focus is of fundamental importance for keyboard users and assistive technologies users.
The current Comments table in WordPress is not the best example, because it lacks some of the features implemented in other tables. I'll refer to the Posts list table for some examples of the interaction model that should be replicated.
This is just an example, there are other cases where focus management will be necessary. From an accessibility perspective, it's a fundamental feature to avoid focus losses. When a focus loss happens, in the best scenario modern browsers are smart enough to try to keep focus in place and start again the tabbing sequence from a surrounding focusable element. In the worst scenario, browsers may completely be unable to do that and fallback focus to the document root. In this case, keyboard users, including screen reader users, would be forced to start navigating content from scratch: one of the worst thing can happen.
Worth noting this browsers "smart" behaviour has historically been introduced at different times. Firefox has this feature since years. Chrome starting from version 50. Safari starting from version 10. Internet Explorer 11 doesn't have this smart behavior and will always lose focus.
I understand in a React world implementing a focus management tool is not easy. There's the need to access the DOM and so some simple DOM manipulation. However, I'm hopeful and confident a smart solution can be found. As a reference, there's been some discussion on Slack around the same issue for Gutenberg, see even if the ongoing experimentation linked there is more about "constraining tab focus", it could be an example of how to get to the DOM in an "isolated" manner.