Skip to content
This repository has been archived by the owner on Aug 14, 2019. It is now read-only.

Focus management #12

Open
afercia opened this issue Jun 3, 2017 · 0 comments
Open

Focus management #12

afercia opened this issue Jun 3, 2017 · 0 comments

Comments

@afercia
Copy link

afercia commented Jun 3, 2017

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant