Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Components: Shift focus into popover when opened #2323
Partially addresses #2306
This pull request seeks to move focus to the first focusable element within a Popover when it becomes opened.
Included are some focus utilities for finding the next available focusable element. A few points:
Verify that focus is moved to first focusable element when opening Inserter:
Verify that focus is moved to first focusable element when opening Post Visibility:
@@ Coverage Diff @@ ## master #2323 +/- ## ========================================== + Coverage 33.16% 33.65% +0.49% ========================================== Files 182 185 +3 Lines 5530 5574 +44 Branches 963 973 +10 ========================================== + Hits 1834 1876 +42 - Misses 3130 3132 +2 Partials 566 566
Great work thanks! There are a few edge cases worth considering though.
This might introduce some more complexity, worth considering if using a library could alleviate development (and maintenance) time.
Quoting from jQuery UI:
So, about naming, this should probably be "tabbable".
One more important consideration: there may be cases where it would be desirable to move focus directly on the popover (or modal) wrapper. Imagine a Popover or modal that contains only text. Where should focus be moved to in that case? The Popover has a wrapper div with
About the Post Visibility, I have a doubt: focus is moved to the first radio button, as expected. But that happens also when it's not the selected radio button:
This is different from the native "tabbing" behavior: when tabbing to a set of radio buttons, only the selected one receives focus. The other ones receive focus when using the arrow keys. I think we cam probably live with this, just wanted to mention it as something worth some testing.
Incidentally this will fix an issue with the content Inserter Menu opening atop the button. Seems the
The more I dig into ally.js, the more I feel it's not a good use of our time to try to reimplement something like tabbable querying from scratch. I am still quite wary about the size of the library, and have tried a few different approaches for remedying. The full library is about 75kb minified. Cherry-picking the
Appears the latest commits are failing because of the ES2015 modules in the dependency. I'm going to sit on this for a bit to think about a direction forward.
Let me know if you have thoughts.
Thinking there are several places in core where there's the need to get the focusable/tabbable elements, filter out the first/last ones, etc. and core is currently doing that with custom implementations that could be replaced with the methods that ally.js provides. In the future, with the advent of JS-based interfaces in core, there will be more and more the need for such methods. I'd propose to consider to adopt ally.js as a core library, and I think 75kb are worth the benefits ally.js introduces.
referenced this pull request
Aug 29, 2017
I revisited this today and spent some more cycles on a few different ideas. Assuming most of our requirements are around finding focusables or tabbables, or some subset of the two, I took to seeing if we could at least use a smaller subset of the ally.js functionality in an minimal abstraction. I quickly found that the dependency graph of their modules are very far-reaching and struggled to not bring in hundreds of kilobytes with even the most targeted of imports.
Instead, I took another stab at another self-implementation, this time much simpler using a
I'm inclined to see how far this takes us, and if it becomes an issue, we can easily swap the underlying implementation, or use ally more directly.
Added in 76875ee.
Will also plan to follow-up this pull request with another for close-on-escape and focus return behaviors.