Try: Always show movers on selected blocks (except during typing)

[chrisvanpatten]

This tries to fix #6272 by always showing movers on selected blocks, unless isTypingWithinBlock is true. This solves some accessibility issues as detailed in the original ticket, but also brings greater consistency between all block tools and less "flickeryness" (new word) for fast-paced mouse users.

It also partially impacts #10090 (but doesn't solve the underlying problem, just makes it less apparent).

Here's a visual:

Now that the block mover is taller, this exposes an overlap issue when hovering a block immediately following a selected short block. I don't have a great answer for that unfortunately, but I think in this case the benefits outweigh that cost (at least for now).

[chrisvanpatten]

@jasmussen @afercia @nosolosw could you take a look at this (sorry for the tags, just trying to think through who would be most affected)?

I don't think it's merge-ready because of the overlapping issue with adjacent blocks, but I'd like to see if this is a viable solution for the accessibility team and brainstorm some ideas to alleviate the overlapping.

❤️ 🚀

[jasmussen]

So, recently we added the drag handle to the side UI. Because we intended to have the hit area be mostly the same as it was before, 28x28px minimum for touchability, the up arrow was moved upwards. The test here is to use this side UI on a single line paragraph, which is the minimum height block we have at 56px height.
So if you try this branch, and place two single line paragraphs after each other, then select the first and hover the second, you can sort of see the problem with the overlap that then happens.

In that vein, although I appreciate this branch — thanks so much for trying — I'm not really sold on it as a benefit.

It's all a balancing act — the movers and drag handle are very useful and helpful when you need them, but they are clutter when you don't. I actually feel the autohiding of them, with tabbability, is a good compromise. If we added on top of that some lovely keyboard shortcut like ctrl+shift+alt+↑ for move up, etc, I think we'd have a good overall balancing.

[chrisvanpatten]

@jasmussen I'm totally sympathetic to that but I know @afercia has made it pretty explicitly clear that keeping them visible while a block is selected is a basic requirement for the a11y team.

I'll let him comment though because perhaps with the recent changes to the block controls and drag handle and such, we can come up with another alternative!

[afercia]

@chrisvanpatten I don't have much else to add to the feedback given on #6272

I actually feel the autohiding of them, with tabbability, is a good compromise

This is a very limited consideration of what the accessibility needs are. Tabbing is only one of the ways to navigate content. Not the primary one for screen reader users (they mainly use arrows). Certainly not much used by speech recognition software users or other alternative devices users. As pointed out in #6272 and in several other issues, the continuous appearing and disappearing of the UI controls is a huge barrier for accessibility. Also for users with motor and cognitive impairments and countless others.

What we've been constantly asking in this project is a way to reduce the continuous appearing / disappearing effect. And we're already doing a big trade-off because, if we had to be strict in our approach to accessibility, then we'd ask to make all the controls visible when a block is selected.

At this point of the project, if the team wants to implement some basic accessibility improvement like the one proposed here, that would be great and very appreciated. If the team doesn't want, then it would be one of the many accessibility barriers that, summed together, contribute in making this product not accessible.

[chrisvanpatten]

I think this is unlikely to change before 5.0, and truthfully I think the movers may need some bigger re-thinking to solve other issues (such as #7646). As such, I'm going to close this, albeit with a very heavy heart :(

(As a bit of editorialising, I generally agree with the sentiment that the UI is sometimes trying to be a little too clever about contextually showing and hiding things. It's an approach that rewards experienced users at the expense of being intuitive for new or impaired users. But I understand that at this stage, with merge approaching, that broad approach is unlikely to change.)