Updates the behavior of the top toolbar fixed setting #47277
Conversation
|
Size Change: +1.39 kB (0%) Total Size: 1.35 MB
ℹ️ View Unchanged
|
draganescu
added
[Type] Enhancement
|
I think my biggest concern about this change is that you lose access to a bunch of tools if a block is selected. As a workflow, a common pattern for me on long documents is "Edit Block > Document Overview > Select Block > Edit Block"; and that workflow isn't available to me with this model without first removing focus from a block. That's easy to do with a mouse, but less trivial or discoverable from the keyboard. One thing that might help with this would be if there is a way to deselect the block while in the top toolbar edit tools, so that if you've navigated all the way back to the editing tools, you can get back to the top toolbar immediately. Alternately, the edit post header controls could be placed in a popover at the beginning of the toolbar edit tools, so that those controls are collapsed rather than removed. |
|
@joedolson in the final shape of this there is a button next to the block tools on the left (an up arrow) than can be used to go back to document tools, and there is a button on the right (a button with the block icon, a paragraph in the design) to go back to block tools, all while having a block selected. This PR is just not there yet. Do you think the toggle solution proposed by the design is good enough? |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
d658902
to
78aebb6
Compare
|
I feel like the toggle to switch between menus should stay in the same position. Effectively, the arrow control to switch to the document tools and the paragraph tool to switch to the block tools are just a single switch that changes between toolbars, and having one of those tools at the start of the toolset and the other at the end feels strange to me. I think it would be more predictable if the switch control was always in the same position. But yes, that would help a lot! |
This comment was marked as outdated.
This comment was marked as outdated.
|
I am not in favor of this change because of context issues. Let me take a moment and paint some thoughts.
Just my thoughts without testing. Right, wrong, not even close? Thanks. |
I think you're right on the money that it's going to be difficult to get this feature right. It isn't the default option though, so one good thing is you shouldn't ever need to enable it. (though I realise it should also work in a good way anyway even when enabled.) One of the main thing that stands out to me is that the tab order is going to be hard to get right. Currently users expect to be able to shift tab from the block to the block toolbar directly without passing through Options, Settings, Publish and Preview buttons. But this change will put those buttons in the way, and that won't be very convenient. It's worth noting that plugins can also add buttons to this area, which means there could be quite a lot of tab stops. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
64099ef
to
6c7c8e8
Compare
|
Here is an idea. How about you visually hide the document tools toolbar and then add events to show it when focus passes through it? That way the experience does not change for keyboard users but you still get the appear/disappear functionality. I simply cannot support adding another tab stop to this area. I was also unaware that there was a slot fill in that area. That really could turn messy one day. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
6c7c8e8
to
861590b
Compare
@alexstine I don't grasp how that would work? Does it mean for keyboard navigation both toolbars will be available at the same time? |
|
@draganescu Correct. Then when the toolbar receives focus, it will be shown visually. Completely removing or hiding the first toolbar from the DOM I do not think is a good idea. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
861590b
to
06e9f82
Compare
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
06e9f82
to
4d42882
Compare
This comment was marked as outdated.
This comment was marked as outdated.
draganescu
changed the title
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
35cd696
to
5cb233f
Compare
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
4050a07
to
3421026
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
@draganescu thanks for the ping. It's important to note that this PR breaks the expected keyboard interaction within the two toolbars. These are based on the ARIA toolbar design pattern. Behind the scenes, there are two I also share all the accessibility concerns already reported by @alexstine and @joedolson so I'll avoid to repeat the same concerns. More general considerationsI went through all the feedback and comments in this PR and in the original issue #40450. Lots of interesting explorations and thoughts there ❤️ However, seems to me this PR is going a bit too far. The original issues to address were:
The initial suggested changes were:
Then, starting from #40450 (comment) the conversation evolved into something entirely different: morphing the document tools into block tools on selection. Which basically means a unified toolbar. I'd like to remind that before WordPress 5.6 the top bar used to be a 'unified' toolbar already. Screenshot from WordPress 5.5:
It was than changes to two separate toolbars, and for good reasons. The split in two was discussed by the design team, see the original G2 issue, and having the two toolbars in two separate rows was the preferred option. See also some a11y considerations here: #20592 (comment). Other important considerations were pointed out in the related pull requests, see #31134 and #30234. This PR would bring us back to a unified toolbar, re-introducing most of the problems addressed two years ago. On top of that, this PR aims to automatically toggle the toolbars visibility depending on the selection state and keyboard interaction. As already pointed out in this PR and in several issues and PRs across the history of this project, 'disappearing and appearing elements' are always a barrier to non-sighted users. I'd add they're always confusing also for sighted users, as they add cognitive load, trigger loss of visual context, and potentially hide important tools thus breaking the user's flow. To me, that's already a good reason to rethink the impact of this PR and limit the changes to the ones that were originally proposed:
There's a lot of additional usability / accessibility considerations that make me think the proposed unified toolbar is less than ideal. Trying to avoid a TL;DR, here's some of the main concerns:
With the current split toolbars, at least it's more clear they belong to two different contexts:
ConclusionI'm not sure this PR would be an actual improvement, as is. To me, the disappearing / appearing elements and hiding important tools are a no starter IMHO. However, I wouldn't be opposed to try the unified toolbar as long as the Document tools stay always visible. No disappearing / appearing. No hidden tools. From there, I'm pretty sure we could refine and address all the remaining concerns. I do realize that would lead us back to the lack of space issue though. As I see it, that's more a design issue. The fixed height ot the top bae and its absolute positioning are part of the problem. The very nature of content on the web is that it should dreflow as necessary depending on the viewport and the device in use. Trying to 'squeeze' or hide the content just to make it fit into an UI that doesn't provide enough space just proves the UI isn't design around the content. |
|
Yeah, I am not a fan of the appearing/disappearing DOM elements either but it seems to be the way of the future with React/Vue/other frameworks. Not the largest issue in the world but things would be less complicated if things did not disappear from the DOM. Something a lot of times sighted people and designers take for granted how hard these interactions can be for people without visual indicators. I totally support conditional rendering for dialogs but it is way over used in Gutenberg even outside of this PR. |
|
I have tried but not succeeded in a different approach, yet I still tink it's possible:
Everything else stays the same for mouse users with buttons that can show and hide document and block tools. My challenge was where to place the block toolbar in fixed mode to respect the bullet requirements above. |
- wraps the edit post header in a slot fill provider - implements a temporary behavior that shows document tools when no block is selected - updates the block tools and parent selector to appear properly in the new place
…slot fill provider
- restores fixed toolbar on mobile viewports - adds hover states to toolbar toggles - adds the correct level up icon - moves CSS to the right files Co-authored-by: Joen A. <1204802+jasmussen@users.noreply.github.com> Co-authored-by: James Koster <846565+jameskoster@users.noreply.github.com>
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
b85ff40
to
0988ac3
Compare
|
Ok, here is the current state: playing around with the DOM position and some heavy focus management, I can achieve the state in the video. toolbar-focus-aria.mp4There still is work to do:
|
|
@draganescu It is working much better. Keep going, you are close. Thanks. |
draganescu
force-pushed
the
try/block-tools-marry-document-tools
branch
from
15a38d0
to
161eb93
Compare
|
TL;DR; there appears to be a way to not break the keyboard interaction at all but it has sent me basically to square one. With the help of @MaggieCabrera and @jeryj I have found a way to reuse the fixed block toolbar and not have to change where it is rendered. Instead, I can simply reposition it on top of the document tools and style it to fit visually there. This has the great advantage that all the keyboard interaction remains the same! No more tricks. However it has some challenges which I am looking into:
As far as the approach in this PR, Alt+F10 is handled by a hook that manages focus when this keyboard shortcut is used. This hook is not specific to block toolbar but to all navigable toolbars. Because this PR puts two navigable toolbars in the same container Alt+F10 always selects the 1st which is document tools. The other thing I still have to see if I can change this in a reasonable way (unlikely). |
|
Closing in favor of #49634 |
What?
Closes #40450
Updates the behavior of the top toolbar fixed setting.
Why?
How?
Testing Instructions
Testing Instructions for Keyboard
N/A
Screenshots or screencast
top-toolbar-parent-selector-focus-show.mp4