You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 14, 2019. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: