Cursor doesn't change to indicate block can be dragged

[chthonic-ds]

Description of the issue In WordPress 5.5 I learned the block drag handle has been integrated into the block toolbar. A click+drag on a block's reordering arrows is the new way to drag a block elsewhere (into a column block, for example).

I see the default and pointer cursor but never the 'grab' or 'grabbing' cursor when dragging a block.

To reproduce

1. Set up an empty columns block.
2. Add a paragraph block and add some text.
3. Click+drag on the reordering arrows of the paragraph block.
4. Observe the cursor never changes to indicate the block can be dragged.

Expected behavior I expect some indication a block is ready to be dragged or being dragged. Not being aware the drag handles had been integrated into the toolbar meant I initially thought it was no longer possible to drag and drop blocks.

I notice in https://github.com/WordPress/gutenberg/issues/23863#issuecomment-663739894 the 'drag' cursor is visible, though the layout and target seem to be an earlier iteration.

Editor version:

• WordPress version: 5.5
• Does the website have Gutenberg plugin installed, or is it using the block editor that comes by default? Default block editor
• If the Gutenberg plugin is installed, which version is it? n/a

Desktop (please complete the following information):

• OS: Windows 10.0.18363 Build 18363
• Browser: Test Firefox Developer and Chrome
• Version: Firefox 80.0b5 and Chrome 84.0.4147.105
• Fresh install of WordPress 5.5, no plugins installed

[ZebulanStanphill]

The accessibility team specifically requested that the up/down mover buttons not use a drag cursor, because all buttons should use the same cursor. See #23759.

A proper solution, then, would be to add a visible, dedicated drag handle, similar to what WP 5.4 had. The biggest problem here, of course, is how much longer that would make the default block toolbar. And so there's the core design problem that needs to be resolved.

[helgatheviking]

+1 to some kind of dedicated handle. This is not obvious at all and I thought the feature had been removed.

[christinablust]

Additionally, at this time this feature HAS functionally been removed for users who prefer the Top Toolbar option, as the (very un-intuitive) method described to drag and drop in 5.5 cannot be accessed unless users are set to the inline block toolbar.

[chthonic-ds]

Considering this issue as initially framed, the cursor state is awkward due to conflating different types of transform—moving a block on a linear path vs. freeform positioning—into one UI device.

I'm also in favour of a visible, dedicated handle. Not everyone takes a template-/pattern-first approach to composing page content, and this makes it important to have a highly discoverable way to drag content in and out of container blocks.

I'd love to have a way to shift menu context between block content tools (bold, italics, etc.) and block transform tools (freeform dragging, moving blocks up and down).

[antonyjsmith]

To provide some perspective from the field literally every single support request I've received from clients in relation to this has been 'why has drag and drop been removed' - hell even I had to check the release notes again to find it. The visual UI updates are jarring enough for our clients and arbitrary, in my opinion, significant regressive steps in terms of what is already in many area a poor UX really do not help.

It feels like there is little or no testing within user groups when literally watching over the shoulder of a single novice user grasping around and clearly floundering is enough to show how desperately Gutenberg needs consistency and clear direction. It's truly depressing to see the work and inevitable rework around these poorly conceived changes in what at it's core could be an excellent tool for users.

[wpfangirl]

I've used Gutenberg since 2018 and someone had to tell me that you could drag a block by clicking and holding on the arrows. I'm not sure in what universe this seemed like good UX. What was wrong with the drag handle we had?

[joedolson]

Responding to https://github.com/WordPress/gutenberg/issues/24506#issuecomment-673016679; what the Accessibility Team specifically requested was that the editor not combine the usage of single controls serving multiple purposes. A drag surface can use the drag cursor, but the up/down move buttons should use a standard button cursor. The problem is with trying to make a single control serve more than one dedicated purpose. We're entirely in favor of having a drag cursor; it just shouldn't be on a button.

[maddisondesigns]

Agree with the above. The removal of the drag handle is a really poor decision. It's ridiculous that the Block Toolbar no longer gives any indication about where you need to click to drag the block, or if it's still even possible to drag the block! Your constant removal and hiding of controls, and elements such as block borders, is making the editor UI go from bad to worse with each new release.

[mariohamann]

Just a quick sketch and idea: What about hiding the up/down and left/right buttons until hover or focus? Would that a problem with a11y? Maybe some aria label while focusing the move area like "arrow up to move up, arrow down to move down" or similiar could help?

[ZebulanStanphill]

@mariohamann Controls shown on hover would definitely be problematic for accessibility. Also, the focus behavior in your mockups would be... weird. The tab order should match visual order as much as possible, and in your mockups, the thing focused to show the mover buttons would end up being focused before the up/left button, which from a visual perspective should come first.

It's worth noting that I've opened #24805 to discuss solutions to the core design issues with the block toolbar that have led to problems like this. Solving the core issue will fix this one as well.

In the meantime, there's an attempt to solve this specific problem in #24852, at the cost of increasing the default toolbar size. Since so many users seem to think drag-and-drop has been removed, this may be a better design for now. Ultimately, though, we'll end up having to solve the other issues like the movers appearing like a single button since they're stacked, and the block transform/style-switcher serving double duty as the current-block indicator... and the longer the block toolbar gets, the harder it is to fit more stuff in and fix the other remaining problems.

[wpfangirl]

@ZebulanStanphill Aren't there already a lot of things that are only shown on hover, though? Why is making up/down arrows show only on hover worse for a11y than not showing a move/drag icon at all? (Mind you, I would prefer having both if it can be done, but I acknowledge the toolbar length issue.) I like @mariohamann's sketch. The four-arrows icon suggests to me that this is what you click if you want to move something. Showing that there are different options for how to move it seems like a reasonable kind of secondary-menu thing. I find the up-down arrows MORE ambiguous as icons, because they could imply different things, e.g. navigating between blocks instead of relocating the block.

[maddisondesigns]

I have to ask again, why is it that the default solution is always to hide icons, and only show them on hover?? The ability to move blocks around your page is one of the most used features in the Block Editor, or any sort of editor like this. Why are all the "solutions" here, hiding these buttons by default. Just show the Block moving arrows and the Block Drag Handle all the time. Stop making it harder for users to edit their page by hiding important and often used functionality!

[talldan]

@mariohamann Thank you for taking the time to work on this. I just want to say that all ideas are welcome, you may get some strongly worded feedback like in this comment thread at times, but that's not representative of how the entire community provides feedback.

As @ZebulanStanphill mentions, keyboard navigation is important. A user should be able to use left and right arrow keys to navigate through toolbar items sequentially, which may be tricky with your design as the buttons only appear once focused/hovered. There's some more information on the pattern here if you're interested on reading up on it, hopefully that'll help: https://w3c.github.io/aria-practices/examples/toolbar/toolbar.html

The 'Select Parent' button that pops up similarly to your design still kind of fits into this as it becomes the first toolbar item and pressing the right arrow key still takes a user through toolbar items sequentially.

[mariohamann]

I think the description of my idea was a little bit too rough - sorry for that (I currently don't have my PC nearby... :)).

So I did another - very low fidelity - sketch:

Description:

1. In default state, the arrows always indicate the movability of a block. While hovering the button, the cursor switches to the well known handler as described by @maddisondesigns
2. While hovering/focusing the button it could expand - maybe even with no or only a light border between the now three areas.
3. The whole area could be focused and arrow up and down directly move the block. This interaction is similar to the interaction @talldan described. Saying: While focussing the move-area, you can simply move with arrows up and down. No switching to other buttons, pressing enter or switching back to revert etc.
4. The arrows could be similar to the ones of the "movable" icon to get a better connection - @wpfangirl ? Furthermore they could be more similar to arrow icons on keyboard to indicate the movability by keyboard.

What do you think?

[mtias]

Solutions that use the toolbar for placing a drag handle are not sufficient since the Top Toolbar option loses that ability.

[ZebulanStanphill]

@mtias Still, there is a drag handle in the toolbar already, and we ought to at least make it visible until we can find a better way to expose it (e.g. a new editor mode/tool or adding drag-and-drop to the Select/Navigation mode/tool.)

As for the parent-block selector being hidden by default, that's a design mistake that needs to be changed, not something that should be copied to other parts of the UI. See #23766. I've tried fixing this in #23800, but I can't progress on that PR because of the other issues with the block toolbar, namely:

• the lack of space
• the block switcher button already confusingly using a block icon as its icon, which means you end up with two very different buttons using the same kind of icon

So to fix the parent-block selector, you first have to change the block switcher to use a dedicated "transform/switch" icon. But when you do that, you lose the block icon indicator, so you'll have to split that out into its own thing. But if you do that, you end up increasing the toolbar size, and if you then put the parent-block selector button into the toolbar, you increase its size even more.

And meanwhile, we're also running into issues where the block movers look like a single button because they take up the same space that a single button would take up, and we need to make the drag handle visible, and fixing those issues will end up almost tripling the space that the mover controls take up.

So if you put all this together, you end up increasing the block toolbar size by 3 buttons, or 4 buttons for nested blocks. So this all ties back to the too-many-controls issues discussed in #24805.

Again, I'd like to reiterate that hiding controls behind hover interactions is not, and should never be the solution. An earlier version of the G2 block toolbar hid the movers behind a hover interaction, and that was changed to make them more visible and improve accessibility. Let's try not to go backwards again. Moving/sliding stuff around on hover is almost always bad for accessibility, and frankly, it's usually just bad for usability in general.

24852 is the best immediate solution currently available to the invisible-drag-handle problem. If you want to see improvement right now, go over there and help get that PR merged. Anything further is going to require bigger changes as discussed in #24805, or else something like modifying the editor tools/modes.

[mtias]

A lot of these last minute tweaks have indeed made some things worse. The separation of the movers from the block type is spurious, since we have controls without a separator coexisting (inline controls like bold and italics). The issue there was one of proximity causing it to seem like a single unit, but it could have been improved.

Semantically grouping these meta-block tools is important. The toolbar with so many separations starts to lose internal coherence. There have also been some thoughts about moving some of the meta controls to the end of the toolbar, which could be worth considering.

In any case, I think we need to solve the drag in selection mode and how to transition. Dragging the block itself (like an image) is always going to win in intuitiveness.

As for the parent-block selector being hidden by default, that's a design mistake that needs to be changed

Pardon me, but I don't agree it's a design mistake. It can be improved upon but I definitely don't think always showing it would be great.

So to fix the parent-block selector, you first have to change the block switcher to use a dedicated "transform/switch" icon.

Why so?

Again, I'd like to reiterate that hiding controls behind hover interactions is not, and should never be the solution.

"Hover interactions" is a bit dismissive of an entire group of design considerations that should not be cast away with a blunt guideline. The toolbar itself is a focus interaction in that it shows based on what blocks is selected. We don't show a toolbar for every block on the page all the time in a permanent way. It's entirely reasonable other specific interactions could work with similar patterns if modeled properly and with the required attention.

[ZebulanStanphill]

So to fix the parent-block selector, you first have to change the block switcher to use a dedicated "transform/switch" icon.

Why so?

Because the parent-block selector button uses the parent block's icon to represent that clicking the button selects that block. But if you put it next to the switcher, then you have two buttons using block icons, which is confusing. Then again, perhaps the parent-block selector should have a dedicated "parent block" icon, though I'm not sure what that would look like.

Also, the switcher shouldn't be using the block icon as its icon because buttons should convey their action in their icons/labels, not their state. A button to transform a block should use an icon that conveys that action, not the icon of the block itself.

We already have this problem with the visibility and publish date controls in the document settings. (See #470.) It would be best to try and fix this problem in other parts of the UI as well.

As far as I can tell, the only reason why the switcher uses the block icon is to save space by serving a double function as both a transform button and an indicator of the current block. From an accessibility perspective, the two should be separate things: an indicator of the current block (presumably with a tooltip containing the block name) and a transform control that uses a transform icon.

As for the whole toolbar grouping thing, I would not be opposed to showing the mover controls in the same group as the transform tool. But unless you style them like every other button (e.g. no stacked buttons, not tiny buttons, just full-size buttons like the ones in the inline formatting toolbar group), you wind up running into confusion where the different buttons look like they might be a single button/select-dropdown.

It's also important to note that since there's multiple movement controls (up, down, drag), it would make sense

As for the order of the controls, I think it's reasonable to move the mover controls before the transform control. The reason why that hasn't already happened, if I recall correctly, is that we wanted to keep the block icon as the first thing in the toolbar. And that brings us back to the issue of the block icon and transform button being the same object when they should be separate entities.

If we simplify things and get rid of all the special-case styling and merged controls, we end up with only one remaining problem: too many things in the toolbar. And at that point, you have to wonder why we're showing so many controls all at the same time. Why are we showing inline formatting controls at the same time as block movement controls? Perhaps it's a sign that we need to start showing controls more contextually somehow. (Hence #24805.)

To throw around a new idea I just had: maybe take advantage of the existing editor tools/modes concept, and make the block movers only available in a dedicated "Movement" tool that allows you to drag blocks from anywhere, but also use up/down, move-to-top, move-to-bottom, and other advanced movement controls in the block toolbar, with no other controls being shown. (Maybe the up/down controls could still be shown in standard "Edit" mode or whatever we call it, I'm not sure about the specifics of how this would all work.)

I'm not convinced that adding drag-and-drop to the Select/Navigation tool makes sense, since that tool was specifically designed for navigating from block to block, and adding more controls might harm its accessibility and muddy the purpose of the mode... telling people to use a mode called "Select" or "Navigation" to drag-and-drop sounds super weird and confusing. Maybe it's fine to have that as a minor enhancement, but it should definitely not be "the" way to use drag-and-drop, unless we decide to redefine what that mode is and what it's called.

I know adding more editor modes is dangerous since it can easily introduce more complexity. But seeing that the block toolbar is already jam-packed with tons of controls to the point where we don't want to add any more, maybe taking advantage of editor modes is the only way to reduce complexity.

(If we did go this route, we should probably make the editor mode more prominent in the toolbar... probably with visible text labels, rather than the icon-only look.)

Anyway, to reel things back in a bit, @jasmussen noted in #24852 that he's working on a different approach to the drag-and-drop issue, so hopefully a good solution will come out of that. Either way, it's good to see action being taken on this issue, because it's a really big problem, and I really hope we can address it before the release of 5.6.

[mtias]

But if you put it next to the switcher, then you have two buttons using block icons, which is confusing. Then again, perhaps the parent-block selector should have a dedicated "parent block" icon, though I'm not sure what that would look like

Ah, I see what you mean.

Also, the switcher shouldn't be using the block icon as its icon because buttons should convey their action in their icons/labels, not their state.

This doesn't make a lot of sense in this case. Many of the toolbar items are buttons containing a stateful representation (current alignment, current color, etc) and they are still able to trigger an action (a dropdown, or a toggle) to change it.

And that brings us back to the issue of the block icon and transform button being the same object when they should be separate entities.

I don't think this is necessarily the case. It's fairly common in writing tools for a select-like button behaviour to be present both showing the current type of a text (i.e. heading 2) and as a way to modify said type. That's how the block type was modelled, just abstracted as a general block tool. It used to be presented as a grid to mimic the main inserter but was changed to be a list to more clearly refer to traditional transforms.

[ZebulanStanphill]

This doesn't make a lot of sense in this case. Many of the toolbar items are buttons containing a stateful representation (current alignment, current color, etc) and they are still able to trigger an action (a dropdown, or a toggle) to change it.

Just because that's how everything is, doesn't mean that's how it should be. It's also worth noting that in the case of things like text/block alignment, all the state icons also happen to work pretty well as general action icons. (E.g. a "align text left" icon also works fine as an "align text" icon.)

In the case of the block switcher, something like a Paragraph icon doesn't even come close to representing the concept of "transform".

It's also important to remember that for ideal accessibility, a <select> ought to have a visible label next to it. The currently-selected option is not supposed to function as a label. So as far as I can tell, the <select> argument just changes the perspective of the problem from "wrong visual label" to "missing visual label".

Relying on icons to function as labels is already supposed to be a last resort when it comes to accessibility. It's even worse when the icons aren't even labeling the control in the first place. And in the case of the block switcher, that's precisely what's happening, in my opinion.

On another note, I've been thinking about the tools/modes solution some more, and the idea of moving the movement controls to Select mode has grown on me. I think it could work, assuming we rename the mode to something that fits its new, wider range of purpose better. (The "Select" name definitely wouldn't work anymore.) Otherwise, I think a separate "Move" mode/tool may be necessary.

[chthonic-ds]

Solutions that use the toolbar for placing a drag handle are not sufficient since the Top Toolbar option loses that ability.

Is this necessarily an issue?

https://github.com/WordPress/gutenberg/issues/23892#issuecomment-657672167 makes the claim "Top Toolbar was a mode specifically designed for people focused on writing", and elsewhere in that issue there's reference to the inline and top toolbars as "block-level" and "text-level".

I admit I don't appreciate the concept of "focus" here, but it doesn't feel unreasonable to argue a drag handle might be out of place in the text-level context (presuming the claim above is true).

[mariohamann]

Solutions that use the toolbar for placing a drag handle are not sufficient since the Top Toolbar option loses that ability.

@mtias I provided an idea some days ago introducing some kind of "layout" mode (instead of "select" mode) which makes it possible to move blocks even without the need of a dedicated "mover" button and therefore being usable with and without toolbar. I would be happy if you could provide some thoughts: https://github.com/WordPress/gutenberg/issues/24751 :)

[jasmussen]

I provided an idea some days ago introducing some kind of "layout" mode (instead of "select" mode)

Is it really necessary with an additional mode one has to select? In apps like Figma and others, the selection tool also allows moving elements.

[mtias]

@chthonic-ds in the sense we should also allow those users the ability to drag blocks. It's ok if there are some differences (like a drag handle in the case the toolbar is detached) but we should still try to not skip the functionality entirely for top toolbar.

[mtias]

Just because that's how everything is, doesn't mean that's how it should be.

And how should it be? Not being facetious, but we are getting into not very productive territory quickly. The entire toolbar works using tooltips instead of labels. Treating the block type differently is what would create an inconsistency.

@mariohamann indeed, that's what "select" was meant to handle! It started as a way to handle clickthrough issues for nested contexts. It then also absorbed the idea of using it as a way to quickly travers the tree of blocks one at a time. It makes sense for it to handle moving as well. The transition between states is something that's an ongoing exploration. Right now it supports escape / enter, for example, but it's also been suggested to use a modifier key at any point to engage with it. That also seems promising, though it would need to ensure not running into common modifier key use at the operating system + browser level, which restricts the options. Transitioning in and out has to be smooth, otherwise modes become an extra hurdle.

[MounirHamani]

You should all check this issue #24898, it contains multiple interesting design proposals.

[christinablust]

Solutions that use the toolbar for placing a drag handle are not sufficient since the Top Toolbar option loses that ability.

Is this necessarily an issue?

For me, yes. I initially came to this ticket because I was baffled about where the drag functionality had gone — I have double vision issues and initially found all the block settings hovering/overlapping above the block to be hard to focus on. So I had turned on the Top Toolbar some time ago, and for me (and other users who had done the same) the functionality to move things in & out of columns/containers had simply disappeared with 5.5.

I agree that it's weird to put some drag-like handle in a top toolbar. My primary confusion arose when the baseline functionality it offers seemed to have been taken away from me entirely. So to me, the issues around top toolbar include:

• Communicating in some way to Top-Toolbar-"Lifers" that they need to change their behavior, and that something that used to be possible (have Top Toolbar on all the time AND have a dragging/in-out mechanism) is no longer the way
• Providing a clear way (any way) to move things IN or OUT of columns/containers instead of just up and down. WordPress already has ways for this for things like menu items, where they can be dragged around or up/down/left/right arrows can be selected (Customizer) or text links can be selected (dashboard: "Move out from under" etc.).

(Is "Move to" supposed to be the way? I just spent a good 5 minutes trying to use "Move to" and my keyboard or my mouse to move a core paragraph into a core column and never succeeded, I have no idea how I'm supposed to do it or if it even can.)

I'm not sure what @ZebulanStanphill and/or @jasmussen may have in the works, but I hope the Top Toolbar folks aren't forgotten. I am much more interested in the ability to move things in and out of levels of the outline/columns/containers than I am about dragging necessarily being the way I do that.

[ZebulanStanphill]

@mtias

And how should it be? Not being facetious, but we are getting into not very productive territory quickly. The entire toolbar works using tooltips instead of labels. Treating the block type differently is what would create an inconsistency.

First of all, the tooltips, textually, are the labels; they match the aria-label of their control. But since these tooltips are only shown on hover/focus, a lot of the weight of control-labeling falls on the icons.

My point is that the icons for most of the other controls in the block toolbar, although they are technically "state" icons, also happen to function as non-textual labels... mostly matching the text of their control's aria-label/tooltip.

(It's also worth noting that some controls in the block toolbar use standard action/control-based icons, such as the Bold and Italic controls or the "More options" button. So it's not like all controls in the block toolbar use current-state icons.)

The block switcher is the odd one out, because it's icon fails to function as a non-textual label for the control. It can't get away with the same 2-in-1 "cheat" that some other controls use.

So here's how I'm suggesting "it should be". I propose that the block switcher/icon be split into two things:

• a (non-clickable) indicator of the current block, appearing at the start of the block toolbar, but semantically not actually being a part of it. (Remember, toolbars should only contain controls.) It could have a tooltip containing the block title. It would serve as the sighted user's equivalent of the aria-label="Block: [BLOCK NAME]" that gets spoken to screen reader users
• a block switcher that uses a proper "transform" icon

I do realize now it's not an entirely clear-cut situation. You could argue the block switcher is fine since technically it follows the same baseline of using an icon showing the current state. But the point still stands that the purpose of the control is not as clear as most of the other controls. I suppose this speaks to a larger issue with the block toolbar: it just doesn't use icons the way that a11y guidelines recommend. It manages to get away with it for the most part since the icons it does use are usually close enough, but I now realize that a complete solution would involve dramatically altering the block toolbar... perhaps resulting in either:

• each control having separate icons for label and current state, or...
• each control having a visible text label followed by an icon for the current state

Anyway, this is getting way off-topic to the current ticket (maybe I'll open a separate issue to discuss this sort of thing), but I hope I made clear the point I was trying to make.

@jasmussen

I provided an idea some days ago introducing some kind of "layout" mode (instead of "select" mode)

Is it really necessary with an additional mode one has to select? In apps like Figma and others, the selection tool also allows moving elements.

In @mariohamann's issue, he's not suggesting an additional mode. He's suggesting the existing modes be altered and renamed.

Speaking of which, the idea of having movement controls moved to Select mode has really grown on me lately. It's interesting to hear that there's already a precedent in existing apps to have a mode that's used for both selecting and moving objects. I think we just need to come up with a new name for the mode that would better fit its purpose.

@christinablust Yeah, I'm pretty sure that "Move to" is supposed to be at least a partial solution to moving blocks in-and-out of nested containers. It's not really clear how to use it at first, though. (And perhaps there's room for improvement there.) I think you have to press Enter to make the move happen, if I recall correctly. If you feel there's anything to be improved, please open an issue about it.

It's also worth noting that if movement controls were moved (heh) to the Select mode/tool, there would be enough room to show "Move to" in the block toolbar (rather than hidden in an overflow menu), and maybe even dedicated "move up one nesting level" and "move into following block" buttons.

[talldan]

• each control having separate icons for label and current state, or...
• each control having a visible text label followed by an icon for the current state

@ZebulanStanphill The toolbar pattern example itself has a a button for a menu that changes state (font family): https://www.w3.org/TR/wai-aria-practices-1.1/examples/toolbar/toolbar.html

And sure it's not an icon, but it also doesn't have a visible label that says "Font".

A user has to know that the thing visually shown is the name of a font to understand that it's a font picker they're interacting with.

The aria-label for the button in this example changes to represent the currently selected font, e.g. "Font: Sans Serif", this is perhaps something that could be used in the block editor to improve labeling on menu buttons.

it just doesn't use icons the way that a11y guidelines recommend

What's the recommendation you're hinting at here? Always handy to have links.

[ZebulanStanphill]

I'm sorry. I worded my response there somewhat hastily and probably too authoritatively. I wasn't referring to any official "guidelines", but rather this passage from the 2018 a11y status report, which didn't even say exactly what I (mis)remembered it as saying:

Accessibility Anti-Patterns

While the efforts towards accessibility have been significant, there has been a strong dependence on methods we consider to be anti-patterns. First among these is a heavy use of ARIA attributes. ARIA, while sometimes necessary, should be considered only as a final option when no native HTML interactions are available.

This reflects a problem in the design process: beginning with custom controls (such as the “switch toggle”), then attempting to make them accessible rather than beginning with standard controls and making a functional interface.

Other anti-patterns incorporated in the design that should never have been under consideration include:

• Placeholders replacing labels
• Icon-only controls (buttons with no visible text label)
• The Switch Toggle and other custom interface elements

Incorporating best practice accessibility into design at the beginning can help avoid these problems.

(emphasis mine)

@talldan Foolishly, I wasn't aware of that toolbar pattern example. One thing I do notice about it is that it emulates the look of a <select>, appearing distinct from standard buttons in the toolbar. In our block toolbar, not only do the <select>-like buttons look different from actual <select>s, but they don't even look different from normal buttons. So there's no way to tell what a button's icon is supposed to represent at first glance, which ties into another passage from the aforementioned report:

Additionally, some toolbar controls behave differently from others. This contributes to the impression of focus moving arbitrarily, since a user cannot readily predict what will happen on triggering these controls.

The combination of behaviors that are self-consistent, but appear inconsistent when you are not clear of the rules governing the changes (such as the block navigation) and behaviors that are not self-consistent (like toolbar buttons) creates a major usability problem.

To our design's credit, however, we do provide actual labels to controls in the block toolbar in hover/focus tooltips, which the "Font family" control in the pattern example lacks.

I must admit I'm not as knowledgeable about a11y as some other people here. Apologies if I've said anything else inaccurate so far.

Back to the immediate topic of the missing-drag-handle, I'd recommend checking out #24852. The latest iteration seems to at least be a better compromise than what we have in master right now.

[talldan]

@ZebulanStanphill It's definitely not a straightforward thing. I think lots of us try to interpret the guidelines the best we can, but sometimes the guidelines aren't even all that well supported.

Regarding the lack of labeling, maybe this is something expanding the option introduced in https://github.com/WordPress/gutenberg/pull/24304 could help with, though it might need to be in conjunction with a 'top toolbar' style toolbar, as I can't imagine there being enough space on the above block toolbar for text labels.

[chthonic-ds]

@talldan Thank you for resolving this!

[maddisondesigns]

Have just updated the Gutenberg plugin to the latest version (8.9.1) and still not seeing a drag handle

macOS Catalina 10.15.6 Firefox 80.0.1

[talldan]

@maddisondesigns It'll be in the next version, 9.0.

[maddisondesigns]

@talldan Ahh ok. Thanks. You should really change the Changelog link in the plugin details popup then. It points to here. If this is the list of changes for the next version, then the plugin is pointing to the wrong place. The plugin needs to point to the changelog for the current version.

How do I find the list of changes in 8.9.1?

[talldan]

@maddisondesigns Oh right, thanks for pointing that out. It's probably because there don't tend to be changelogs for patch releases. The right link should have been this one: https://github.com/WordPress/gutenberg/compare/v8.9.0...v8.9.1

It had just a single backwards compatibility fix - https://github.com/WordPress/gutenberg/pull/25046.

I'll mention it to see if the release process needs to be changed. It may have just been a manual error.

[maddisondesigns]

@talldan Thanks for that 👍

[talldan]

Double checking, the link from the plugin page is to here: https://github.com/WordPress/gutenberg/releases/tag/v8.9.1

Usually the changelog would appear on this page, but as patch releases tend to be made very quickly to fix a specific issue they're usually not compiled.

The 52 Commits to master link is something that github shows automatically for every release, but it shows stuff in the next release. While it's misleading it can't be removed.