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

Block: Consider changing focusable block wrapper from outer to inner #6687

Open
aduth opened this Issue May 10, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@aduth
Member

aduth commented May 10, 2018

Previously: #5102 (comment)

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

<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:

<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

This comment has been minimized.

Contributor

jasmussen commented May 14, 2018

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

This comment has been minimized.

Contributor

afercia commented May 14, 2018

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

This comment has been minimized.

Contributor

afercia commented Sep 17, 2018

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

This comment has been minimized.

Member

aduth commented Oct 12, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment