Size Change: -193 B (0%)

Total Size: 1.42 MB

_{compressed-size-action}

Flaky tests detected in 9819c41.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5427134294
📝 Reported issues:

• [Flaky Test] Should show the expected block transforms on the list block when the quote block is removed #40370 in specs/editor/various/block-switcher.test.js

It's possible that this has been fixed in @ariakit/react@0.2.12. I made a change on ariakit/ariakit#2601 that was related to a different issue but may also impact this one.

@diegohaz

Thanks for the update! But I've updated the package and tested it locally, and it doesn't seem to solve this problem 😅

I noticed this bug in trunk but couldn't figure out where it came from. Once it does mount, tab will place you in it but after a shift+tab to Options button.

@diegohaz

Thanks for the update! But I've updated the package and tested it locally, and it doesn't seem to solve this problem 😅

Oh, thanks for testing! That was my best guess since I couldn't really find any other big difference between Reakit and Ariakit that could've impacted this behavior.

Just to be sure: did you follow the Updating Existing Dependencies guide to update the package?

Just to be sure: did you follow the Updating Existing Dependencies guide to update the package?

Oh, I had missed this page. I simply tested the following steps:

• Manually change the subpackage version here
• Run npm install in the project root

I assumed it was updated correctly because I saw the following diffs:

diff --git a/package-lock.json b/package-lock.json
index f9e56d0a6b..6b2f4d5f33 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -17418,7 +17418,7 @@
                "@wordpress/components": {
                        "version": "file:packages/components",
                        "requires": {
-                               "@ariakit/react": "^0.2.10",
+                               "@ariakit/react": "^0.2.12",
                                "@babel/runtime": "^7.16.0",
                                "@emotion/cache": "^11.7.1",
                                "@emotion/css": "^11.7.1",
diff --git a/packages/components/package.json b/packages/components/package.json
index 74220c1101..455d3daa3c 100644
--- a/packages/components/package.json
+++ b/packages/components/package.json
@@ -30,7 +30,7 @@
        ],
        "types": "build-types",
        "dependencies": {
-               "@ariakit/react": "^0.2.10",
+               "@ariakit/react": "^0.2.12",
                "@babel/runtime": "^7.16.0",
                "@emotion/cache": "^11.7.1",
                "@emotion/css": "^11.7.1",

I will test again later according to the documentation procedure.

Hi folks, what's the status of this PR? Is it being actively worked on? Asking because I notice the linked issue is tagged high priority, is in the 6.3 release board, and RC1 is scheduled for next week. Any chance we can get this fixed beforehand?

This isn't actively being worked on, as we're unsure it's even a good idea. It was more of an exploration to see if it was even possible. We can definitely pick it back up, but because it's such a large change in the behavior, it's unlikely to be more stable than reverting to reakit.

Before we put more time into this, we should figure out:

• Why the upgrade broke the shift+tab behavior (is it caused by a bug with the implementation of ariakit in gutenberg, or a bug within ariakit?)
• If the delayed rendering is caused by ariakit, is it a bug or a feature over reakit? For example, is it somehow far more performant and something we should implement?

The shift + tab behavior in the editor has been debated before. Is this a moment we should use to reconsider the behavior of navigating between toolbars?

I know this comment raises a lot more questions than it answers, but I think it'll be useful to figure these out so we can choose the best direction.

@jeryj I would be in favor of dropping Shift+Tab for toolbar since we have Alt+F10. This is a very common shortcut on Windows, F10, so Alt does not make it a very big ask. All the Microsoft Office products use F10 for ribbon navigation.

@alexstine I was looking at that behavior in other editors too. Two questions for implementing that behavior:

1. Is there a common shortcut for returning from the toolbar? If you arrive at the toolbar using alt+f10, should an escape keypress return you to the block as long as you're still within the block toolbar?
2. Since we have multiple toolbars, should alt+f10 cycle you through the available toolbars for that block?

Looks like the regression is fixed by upgrading ariakit to v0.2.12. I'll open a PR.

Looks like the regression is fixed by upgrading ariakit to v0.2.12. I'll open a PR.

That's great! Thanks @diegohaz! I tried this earlier today but it wasn't working for me. It's 100% possible I was doing the upgrade path wrong. I tried:

• removing ariakit from package.json and components/package.json
• reinstalling all packages
• Adding ariakit 0.2.12 back in.
• reinstalling all packages again

Regardless of other considerations, I think this is a great exploration. There does seem to be some advantage to be had. Is there even a tradeoff? I.e. what is gained by removing the toolbar from the DOM?

@stokesman - I agree that having it rendered once but offscreen is a better solution overall, provided it works as expected everywhere. I wasn't sure if it was opening a can of worms of potential bugs though.

@jeryj Answers.

1. Is there a common shortcut for returning from the toolbar? If you arrive at the toolbar using alt+f10, should an escape keypress return you to the block as long as you're still within the block toolbar?

Yes. Although, we'd probably have to change blocks such as navigation to have role="application" so we do not force Windows screen readers to switch modes on escape key press. This would need testing. This would work fine for Mac but pressing escape could cause Windows screen readers to switch into virtual mode which would mean we'd have little control over focus.

2. Since we have multiple toolbars, should alt+f10 cycle you through the available toolbars for that block?

Probably so. This practice should have never happened in the first place. It is confusing without vision. If it is going to happen, tabs should be used to section the toolbars. Yet another oversight from lack of accessibility involvement from the start.

@alexstine

If it is going to happen, tabs should be used to section the toolbars.

So, ideally, there'd be one toolbar on the page, and using tab would move you between the toolbars?

For example, if you're on a caption in an image block you now have three toolbars in different parts of the DOM:

• Caption toolbar
• Image toolbar
• Document toolbar

If we were able to position them together in the DOM, one alt+f10 press could bring you to the caption toolbar, then you could use shift+tab to reach the higher level toolbars? Or would it drop you to the start of the toolbar and you could press Tab 2x to reach the caption toolbar?

@jeryj No, I mean actual TabPanel implementation. It should be presented as an actual ribbon because in it's current state, there is no way for a non-sighted user to know there are multiple toolbars. For example, Alt+F10 should move you to the closest toolbar then you can press Shift+Tab in to the TabPanel to select another toolbar. Using your example:

1. Alt+F10 would focus the caption toolbar since that would be the closest.
2. Shift+Tab to the TabPanel would land you on Caption tab.
3. Press Right or Left Arrow key to focus Image tab and press Enter.
4. Press Tab to enter the Image toolbar.

The problem becomes communicating to users that there are multiple toolbars in the first place. If you had no vision, what indication is there currently to tell you multiple toolbars exist? None.

Shift+Tab and Tab should be restricted to the current block and should not allow you to change context. For example, you should not be able to Shift+Tab from the image toolbar into the top toolbar as the top toolbar is global, you cannot take action on the selected block from there. We always have landmark navigation to reach other regions of the editor.

Checkout Microsoft Word for inspiration. I give Microsoft a lot of trash for having some terrible products, Teams being one of them, but the Office suite is solid, works very well and always has.

Gutenberg does not work well for screen reader users because there are too many implied visuals. Need to figure out how to change that.

Thanks.