Block: Consider changing focusable block wrapper from outer to inner

[aduth]

Previously: #5102 (comment)

Currently the block's focusable wrapper is the top-level (root) element of block-list/block.js:

gutenberg/editor/components/block-list/block.js

Lines 480 to 498 in 2b76039

	<IgnoreNestedEvents
	id={ blockElementId }
	ref={ this.setBlockListRef }
	onMouseOver={ this.maybeHover }
	onMouseOverHandled={ this.hideHoverEffects }
	onMouseLeave={ this.hideHoverEffects }
	className={ wrapperClassName }
	data-type={ block.name }
	onTouchStart={ this.onTouchStart }
	onFocus={ this.onFocus }
	onClick={ this.onClick }
	onKeyDown={ this.deleteOrInsertAfterWrapper }
	tabIndex="0"
	childHandledEvents={ [
	'onDragStart',
	'onMouseDown',
	] }
	{ ...wrapperProps }
	>

This element includes as descendents both the UI of a block (its movers, toolbar, menu) and the editable form of the block itself. The impact here is that when a block wrapper is focused (e.g. when no other text inputs exist as in a newly inserted image placeholder block), the user must tab through all of the movers, toolbar buttons, and menu before reaching the content of the block itself.

It's been proposed that instead the first tab should transition focus into the block's editable form, and that Shift-Tab would reverse navigate through focusable items in the surrounding UI:

The idea being that right after your insert it, you can press delete, and it's gone. Or you can tab into the contents of the block. Or you can shift tab into the side UI and block toolbar.

In implementation, this would be represented by changing the focusable wrapper to the IgnoreNestedEvents element immediately wrapping the block editable form:

gutenberg/editor/components/block-list/block.js

Lines 544 to 551 in 2b76039

	<IgnoreNestedEvents
	ref={ this.bindBlockNode }
	onDragStart={ this.preventDrag }
	onMouseDown={ this.onPointerDown }
	className="editor-block-list__block-edit"
	aria-label={ blockLabel }
	data-block={ uid }
	>

Open questions:

• So far as usability / accessibility, is this really an improvement? Would the user expect to need to reverse tab into block options after it becomes selected?
• Are there other options to make the editable content more easily reachable after inserting? We could lift the restriction of only text inputs being considered for block auto-focus, thus allowing the image block's "Upload" button to be focused immediately. The downside is that this conflicts with desired workflows of either deleting immediately after inserting an image block, or pressing Enter to immediately continue inserting content.

Whichever behavior is decided upon should be reflected with end-to-end tests verifying the expectations.

cc @jasmussen @afercia

[jasmussen]

So far as usability / accessibility, is this really an improvement? Would the user expect to need to reverse tab into block options after it becomes selected?

I believe this is the current editor's behavior? I know it's not ideal, and I believe this is what Andrea hoped to solve with the unified "ctrl/cmd" command to enter the toolbar back in the day.

Also an open question how, if any, the navigation mode that @youknowriad is working on might play into this. If for example you are in "isEditing mode" when you are typing, does that change the tab behavior? Probably not but worth mentioning.

[afercia]

Would the user expect to need to reverse tab ...

It's very unlikely users would expect that, as all the previous controls would be basically "skipped" and some users wouldn't have a clue they even exist. Also, visual order and tab order should always match.

Are there other options to make the editable content more easily reachable after inserting?

From an accessibility perspective, it's the order that matters. If the editable content is the main content, then it should be placed as first element in the block keeping the native tab order. I'd warn against programmatically managing focus to assume a specific workflow. That would be just an assumption, while often users find several, different, unexpected, ways to use an UI.

I understand the formatting toolbar at the top is useful for mouse users. However, other users have different needs. Mobile brings in new issues too. After several months we're using this UI, I'm starting to think there's no single solution able to address all users needs. I'd tend to think this is probably one of the cases where an option would make sense.

See related #6224, #3976 (proposal to place the formatting toolbar below the block), #3961, #5694.

[afercia]

Discussed during today's accessibility bug-scrub: @aduth is this still on the radar? We still tend to think the best option is to not play with focus and just try to get a natural tab order that makes sense.

[aduth]

Since it's been some time since I've considered this, it's not clear upon revisiting what precisely should be done here.

[afercia]

See also #12648 with some considerations about initial focus and nested blocks.

Noting a clear pattern for the blocks initial focus still needs to be addressed. It's challenging because of the different interaction across different blocks and because the block UI controls order is not ideal. It's a broad issue that would probably need some dedicated meeting 🙂

[youknowriad]

I believe this should be closed now since we only have a single wrapper.