WritingFlow should exclude standard input fields

[afercia]

In some cases, having WritingFlow kicking in risks to disrupt the standard interaction with standard input fields and moves the caret outside of the field, even it that's not what users would expect.

Consider for example the permalink edit field:

when the mini-form opens, it should be possible to use the arrow keys normally, as users are used to. Instead, when the caret is at the end or at the beginning of the field, pressing the right arrow or the left arrow key moves the caret to the following block or to the post title.

In the post permalink, this behavior is more evident because this UI is, in a way, visually "detached" fro the post. What about other input fields, for example in the shortcode, embeds, video, etc. blocks?

I'd say the most expected behavior would be trying to emulate the native behavior as much as possible. When pressing left, right, Home, End (and related keys combination e.g. Cmd+Left), the caret should stay within the input field. Being unexpectedly kicked out from the input field is a very confusing experience also for assistive technology users.

In this case, when the caret is within native input fields, I'd propose to use just the Up and Down keys for WritingFlow (doing nothing when modifier keys are used). Would this be an acceptable trade-off?

[rianrietveld]

I'd propose to use just the Up and Down keys for WritingFlow (doing nothing when modifier keys are used). Would this be an acceptable trade-off?

Seems fair to me.

[anevins12]

I would get rid of the up and down interactions in fields for future proofing, in the case that we might introduce radio fields

[afercia]

@karmatosed is it possible to prioritize this issue and put it somewhere for 5.0 instead of "ideas"? we've discussed it during today's accessibility bug-scrub and agreed it's something pretty important to try to address properly before release.

[karmatosed]

@afercia absolutely. Would you be able to summarise here why? Just to close the loop from a Slack meeting.

[afercia]

Sure. The point is, when the caret is within a standard input field, user (especially keyboard and screen reader users) expects the caret to behave as usual: using the arrow keys (and any combination with Ctrl/Cmd etc.) just moves the caret within the input field. Instead, in Gutenberg the behavior of WritingFlow kicks in and as soon as users use the arrow keys, they're kicked off from the input field.

This is extremely confusing, as users would expect to operate normally within an input field.

[swissspidy]

It's not only confusing but also super annoying since the permalink form disappears when hitting the arrow key and I lose all modifications I was about to save.

[afercia]

Thanks @swissspidy about the permalink UI you may be interested also in #5494 (comment)

[afercia]

See also #9583

[afercia]

Discussed during today's accessibility bug-scrub: @mtias any progress on this issue, how can we help this issue move on?

[aduth]

In this case, when the caret is within native input fields, I'd propose to use just the Up and Down keys for WritingFlow (doing nothing when modifier keys are used).

This seems reasonable to me, though for exhaustiveness' sake, it might be worth doing an audit of where we do expect ArrowLeft & ArrowRight to navigate between blocks (at least Paragraphs), the types of elements they use, and whether they'll always fall under this definition.

I expect this would include <input> and <textarea>, but exclude elements with contenteditable attributes?

[aduth]

I expect this would include <input> and <textarea>, but exclude elements with contenteditable attributes?

Which naturally leads to exceptions: Do we (and what if a developer wants to) use an input element in cases where we'd expect ArrowLeft and ArrowRight to continue writing flow? Conversely, do we have blocks where we use contenteditable for elements which assume the behavior of a standard input? I think it'd be perfectly fine to say that these use-cases would be unsupported / discouraged, more to highlight expected conflicts with varying behavior by the element type.

Another option is to make the ArrowLeft & ArrowRight behavior specific to the RichText element.

[afercia]

I expect this would include and <textarea>, but exclude elements with contenteditable attributes?

That would be the idea.

Another option is to make the ArrowLeft & ArrowRight behavior specific to the RichText element.

Hm I guess it would be simpler perhaps, but what when an user tabs away from a native input field and lands, say, on a button? Should WritingFlow work on a button? To clarify visually, see the screenshot below: when tabbing away from the input field, should arrowing on one of the buttons bring me to the paragraph below? Note: for screen reader users, that would be highly unexpected.

[aduth]

Another option is to make the ArrowLeft & ArrowRight behavior specific to the RichText element.

Hm I guess it would be simpler perhaps, but what when an user tabs away from a native input field and lands, say, on a button?

In the original comment, I meant in terms of handling ArrowLeft & ArrowRight only while within the RichText (the source of the interaction, not the destination). But now that you mention it, destination could be a factor as well, since would it be expected that in your example above, if we press ArrowLeft from the beginning of the paragraph, we hit one of the fields within the Video block (the text field even)?

[aduth]

Pull request at #9978

[afercia]

would it be expected that in your example above, if we press ArrowLeft from the beginning of the paragraph, we hit one of the fields within the Video block (the text field even)?

WritingFlow clashes with the way screen readers use arrow keys. When using a screen reader:

• with Safari+Voiceover: Control-Option-Right arrow or Control-Option-Left arrow
• screen readers on Windows: Down arrow or Up arrow

these keys are used to navigate content, that means all content not just focusable elements. They're used a lot by users, and it's basically the main way to navigate content sequentially.
Additionally, on Windows screen reader use brose mode or focus mode. In browse mode, arrows navigate content. In focus mode, within a form control, they stop navigating content and behave natively to allow native interaction with form controls.

So back to the example:

press ArrowLeft from the beginning of the paragraph, we hit one of the fields within the Video block (the text field even)

• in browse mode it would be unexpected because it should just navigate to the previous content, whatever it is (text, button, etc.)
• in forms mode it would be unexpected as well, because arrow keys within a form field should behave natively, i.e. move the caret in the input field and stay within the input field