Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Alt+F10 to always select the block toolbar #50667

Open
draganescu opened this issue May 16, 2023 · 10 comments
Open

Change Alt+F10 to always select the block toolbar #50667

draganescu opened this issue May 16, 2023 · 10 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). General Interface Parts of the UI which don't fall neatly under other labels. Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.

Comments

@draganescu
Copy link
Contributor

draganescu commented May 16, 2023

What problem does this address?

Currently Alt+F10 is a keyboard shortcut described as "Navigate to the nearest toolbar". This sort of behavior creates big problems when we want to alter the UI, because the notion of "nearest toolbar" is variable by definition and that causes unexpected focus management.

The most recent situation where we met this problem was in implementing the new Top Toolbar improvements:

  • the original implementation which used Slot/Fill to move the fixed toolbar in the Interface header broke the Alt+F10 shortcut, as now with the "Top Toolbar" setting the "nearest toolbar" in the DOM is not the block toolbar anymore
  • the alternate implementation which eventually got merged tried to preserve Alt+F10 's behavior by keeping the Top Toolbar in the same DOM spot and positioning it with lots of CSS

The problem is we need to revert to the original implementation because absolutely positioned chrome elements are ruining the expectations of plugins that hook into the editor UI. Elements of the editor chrome should just flow horizontally and vertically. Absolutely positioned elements with z-index higher than the Interface:

  • ruin some plugins today
  • block us tomorrow to add new plugin available slots, because they may fall "under" the absolutely positioned UI

The fragility of Alt+F10 being a shortcut for "nearest toolbar" is also visible in the recently fixed:

... where we've seen how it can be very easy to act on multiple DOM elements by trying to be overly clever.

What is your proposed solution?

I propose that we make Alt+F10 always focus the block toolbar, wherever in the DOM the block toolbar is. For navigating the interface we still have the regions and the shortcuts to move through each of the regions.

@draganescu draganescu added [Type] Enhancement A suggestion for improvement. General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback. Needs Accessibility Feedback Need input from accessibility [a11y] Keyboard & Focus labels May 16, 2023
@jeryj
Copy link
Contributor

jeryj commented May 16, 2023

I propose that we make Alt+F10 always focus the block toolbar, wherever in the DOM the block toolbar is. For navigating the interface we still have the regions and the shortcuts to move through each of the regions.

I'm fine with this. I had a similar thought with #49778. It ended up being tricky (for me) to implement. I'd be happy to pair with you on this!

@alexstine
Copy link
Contributor

Hmm, I do not think you will be able to do this due to some complications right now. For example:

  1. Insert an image block and select or upload an image.
  2. Select the Caption button and focus will be placed in the field.
  3. Pressing alt+f10 will focus the nearest toolbar which is the caption formatting sub-toolbar, not the main block toolbar.

Until these undesired messes are cleaned up in the block editor, things like this are simply going to have to wait due to mistakes made at the beginning.

Thanks.

@alexstine
Copy link
Contributor

I think @tellthemachines actually explained to me about how these toolbars work so sending a mention. @ellatrix was also involved in making this happen with writing flow.

@draganescu
Copy link
Contributor Author

Until these undesired messes are cleaned up in the block editor,

How would we clear them? Do we have any solution?

@alexstine
Copy link
Contributor

Not at this point, no. The multi-toolbars work great for the sighted, but not so much for keyboard users. We should have thought about this at implementation but not much we can do about history now. It will need to be refactored somehow and will block this issue until done.

@draganescu
Copy link
Contributor Author

@alexstine doesn't it help that the smaller formattig toolbars are focusable with Shift+Tab?

@alexstine
Copy link
Contributor

@draganescu No, not really. Alt+f10 is kind of the global shortcut everywhere for finding toolbars. I think it would be highly confusing to have shift+tab find one toolbar and alt+f10 find another. In reality, there should only be 1 toolbar, that would make things much easier and this would not be a problem. Finding a way to communicate this context to users about multiple toolbars is not easily possible especially after a change like this.

@alexstine
Copy link
Contributor

What I am getting at, shift+tab will likely not find toolbars in the future, it will be reserved for navigating content in block placeholders, fields, etc. so I would like alt+f10 to do only toolbar-related focus.

@ellatrix
Copy link
Member

Can Alt+F10 cycle through the available toolbars? Maybe add Shift for reverse.

@alexstine
Copy link
Contributor

No, I think not. This would go against how other popular web platforms implement this feature. What might make sense is alt+f10 always jumps to closest toolbar and then a second press of alt+f10 could jump to the other toolbar. On initial press, it should always jump to closest. That make sense?

@priethor priethor added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). and removed [a11y] Keyboard & Focus labels Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). General Interface Parts of the UI which don't fall neatly under other labels. Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

5 participants