Edit mode: arrow up/down should not move to other blocks

[alexstine]

When using a screen reader in Gutenberg edit mode, pressing up/down arrow while in a block can cause the blocks to change. E.g. let's say I have a heading, paragraph, and quote on the page. If I am busy typing a paragraph out in edit mode and then want to go back and read what I have so far, I might press CTRL+HOME to go to the beginning then down arrow to read line by line. The problem becomes if I reach the end of the content and don't realize it, I could switch to the quote block and not even realize it.

I would like to see this feature adapted that way you must exit edit mode by pressing Escape before you can change blocks. This way the user knows exactly which block they are in at all times. This would be similar to how the Voiceover screen reader works on Mac OSX. When you want to perform a specific action or explore a structured element, you interact with that element and nothing else. I am thinking this type of approach would work really well for editing content in blocks that way a user never gets confused as to where they are from an accidental press of the up/down arrow when at the top/bottom of the block.

One possible alternative would be to add a setting that allows the user to choose whether or not to trap focus in the block or not based on if the user is in edit mode or not. This would be a good solution as well since this would allow for the user to make the decision on what they feel most comfortable with.

Thoughts, opposing opinions?

[talldan]

@alexstine It'd be great if you could provide some numbered Steps for reproduction. I haven't quite been able to reproduce what you describe, but then I think CTRL+HOME is a windows specific thing.

[alexstine]

@talldan This is how you can replicate.

1. Open Gutenberg.
2. Add a heading block and paragraph block.
3. Go in to "edit mode" for the paragraph block and write some example text.
4. Screen reader users can use their up and down arrows to read whole lines at a time. If you press up arrow while your cursor is on the first line in the paragraph block, your cursor will bounce in to the heading block.
5. If you are in the heading block, pressing down arrow will bounce you in to the paragraph block.

My recommendation is to change this so you can not jump from block to block in "edit mode", you would need to be in "navigation mode". This is to prevent accidental block switching while editing content.

Makes sense?

Thanks.

[talldan]

That's great, thank you 😄

[MarcoZehe]

OK, so I was just asked for review on the associated PR, but I must admit I am really torn about this. On one hand, this would put editing on parity with how mobile Gutenberg works in the WordPress iOS and Android apps, which is a good thing for consistency.

On the other hand I am not seeing part of the problem while editing in Firefox and NVDA. If I change blocks due to up or down arrows, NVDA tells me that I changed blocks. But on the other hand I've been caught by surprise by unexpected block changes, too.

I am just worried that this might break some expectations, like how many people do actually rely on arrow keys changing blocks. I am not so much thinking about screen reader users, but more about sighted keyboard users who try to cling to the notion that Gutenberg is actually an editor. In other editors, leaving a paragraph changes to the previous or next, depending on direction. But without actual data, AKA complaints, we probably won't know until we've tried.

[afercia]

To clarify: in the Gutenberg context this feature has been named "Writing Flow".

It is one of the most argued features in the editor. The editor team feels it's an important feature. The accessibility team is very torn on it.

As usual, there's a big difference in how things work visually vs. semantically and the expected keyboard interaction. Being able to navigate the whole content area with the arrows key may make sense if the content area was a unique application. However, it's actually divided in blocks and each block is semantically an editable input, and communicated as such.

Also, arrow keys are reserved keys for standard navigation with screen readers. Using arrow keys for other purposes is extremely confusing for screen reader users.

Worth also noting that in the initial accessibility recommendations posted on March 2017, it was recommended to treat each block as a sort of "modal", at least in terms of interaction. See #297

The block concept has evolved since then but it still makes a lot of sense to provide a standard arrows key behavior while editing a block. That is: at the very least, disable "Writing Flow" while editing a block.

[mtias]

Being able to traverse blocks using the keyboard while writing and editing is most definitely something we want to preserve as it's one of the first and most important design imperatives for the editing experience of the document. If users cannot move between paragraphs using arrow keys it'd be a considerable subversion of expectations for a writing environment. The technicality that every paragraph is a block should not be exposed detrimentally to users.

It seems the part that can be worth revising is if this behaviour makes sense for screen-readers as a whole — assuming the communication of where you are in the document is alright at the moment, as @MarcoZehe mentions — or if it should be constrained instead. How can we gather more insight regarding what the expectations of users relying on screen readers would be? Is there a way to enact smarter detection to make this behaviour the default if that is deemed to be the preferred editing mode for such a context?

[alexstine]

The real problem I see is if multiple paragraph blocks shouldn't be known to users, this actually creates a bigger accessibility issue. Since you are able to access block toolbars, my understanding is you can have different styles in different paragraph blocks. Blocks should be a self contained concept, not an open flowing one as such concepts do not work well in accessibility.

Open concept works great in classic editor and applications such as Google Docs, but not in Gutenberg since the inherent principal of blocks is to have some separation of content.

That's my understanding anyway... Thanks.

[afercia]

Being able to traverse blocks using the keyboard while writing and editing is most definitely something we want to preserve as it's one of the first and most important design imperatives for the editing experience of the document. If users cannot move between paragraphs using arrow keys it'd be a considerable subversion of expectations for a writing environment.

@mtias I can't express how much your statement is based on a series of wrong assumptions. I have no idea what a "design imperative" is. I guess that's just what you personally envisioned the block editor should be.

editing experience of the document

The block editor is not a document. It's a series of contenteditables that are semantically communicated as textarea elements, plus other form controls given by blocks like Image, Gallery, etc. As such, it's a form-based application and perceived as such by any software. Since it's perceived and communicated as a series of form elements, users expect the native interaction of form elements.

Instead, what you're "envisioning" is a web application à la Google Docs but that's a completely different semantic and interaction pattern. In such applications, any semantics and interaction needs to be rebuilt via scripting. I'm very sorry, but I'm also pretty sure you don't have the knowledge to fully understand what the difference between the two patterns is, though as accessibility team we tried to explain this point a few times over the last 3 years.

If users cannot move between paragraphs using arrow keys it'd be a considerable subversion of expectations for a writing environment.

• What group of users are you referring to? Seems to me there's the usual, big, bias in considering only "abled" users, which is very arguable in a project and community that claims to be inclusive and dedicated to support diversity
• Any data to backup this statement?
• As I see it, it's a moot statement anyways because within the post content paragraphs and other contenteditable-based blocks are mixed up with other kind of blocks where navigating content via arrow keys is certainly not an expected behavior
• WritingFlow is basically a big hack that proved over the last 3 years to break many expected interactions
• We should develop based on web standards rather than single persons' envisionings

Is there a way to enact smarter detection ...

I'd also like to remind it's not just about screen readers. All keyboard users are impacted.

Also, we touched the point of assistive technology detection a few times over the last years and remarked that's ethically not acceptable. Not to mention big privacy concerns. But here it is, once in a while someone proposes detection again and again.

Once again, the accessibility team recommended 3 years ago, on March 2017, that all blocks should have a sort of "modal" behavior, meaning that once users are editing a block the interaction should be constrained within the block and be the expected interaction. See #297. Instead, right now with some standard keys combination that are commonly used with form controls, users are unexpectedly catapulted to other block, or may trigger other unexpected behaviors.

Any form control expected, native, keyboard interaction should always be honored. That means all the keys combinations that natively work for form elements to move through the inputs content, select parts of the content, etc., should work in the Gutenberg editable fields as well. Instead, WritingFlow is breaking all that in many, many, ways.

I'm also guessing that no one has actually tested WritingFlow recently, as it seems to me it's broken in at least a couple serious cases, will try to create a separate issue as soon as I have some time.

Lastly: we started discussing this issue during last weekly accessibility meeting: the proposal so far is:

• at the very least, provide a user option to completely disable WritingFlow, which should be technically pretty simple
• optionally, consider to remove WritingFlow from Edit mode by default

We'll continue the discussion at the next weekly meeting.

[ZebulanStanphill]

It's worth noting that you can't navigate up the block hierarchy in navigation/select mode right now. You have to use edit mode or the block navigation interface to move up the block hierarchy. We'll want to fix that soon alongside whatever changes we make as a result of this discussion.

Trying to make edit mode act like a standard text document editor is misleading, in my opinion. It's not a document editor; it's a block editor. We can't hide this from the user, nor should we.

If Gutenberg was a text document editor, the rich text formatting controls would be applicable everywhere, across multiple paragraphs and other objects. But even among text-related blocks, some have a different set of formatting controls as the others. One of the big advantages of blocks is the ability to tailor the available controls to the specific block being edited.

The ability to use arrow navigation to move out of the current block goes against the whole point of the edit mode versus navigation/select mode split. There should be a clear separation between the two.

[afercia]

It's worth noting that you can't navigate up the block hierarchy in navigation/select mode right now

I think this is one of the WritingFlow breakages I mentioned above. In my testing, in navigation mode the cursor does move up and down but the page doesn't scroll. Which defeats the purpose of WritingFlow entirely. Will create a new issue after I reproduce consistently.

[afercia]

As promised, I created two new issues to highlight some pretty serious buggy behaviors in WritingFlow, see #22420 and #22424

[mtias]

I can’t express how much your statement is based on a series of wrong assumptions.

@afercia To be honest, the main wrong assumption, from my perspective, is to systematically employ opinion as if it were an inalienable truth and imply that any other person that disagrees with a specific take on interaction models is someone who doesn’t care or understand technology. It is disappointing, patronizing, and frankly unfounded. I’d appreciate if we didn’t resort to ad hominem disparages when faced with disagreements or put into question the ethical integrity of other contributors.

I'm happy to discuss at length the implications of decisions and how to improve upon them. I only ask, particularly in these stressful times that the world is going through, to assume positive intent from everyone. There is no rule of standards that would be able to predetermine how everything ought to be built, there is room for ambivalence (already expressed in this thread, for what is worth) and it requires critical examination to address all the nuances involved in pursuing a high quality product.

[mtias]

@alexstine yes, you are most right that paragraphs-as-blocks allow to contain certain functions that apply only to that block, though it could also be mapped as an expansion of inline formatting tools (bold, italics, etc) to the level of block units.

The biggest challenge is the editor tries to behave in some ways like a regular writing environment (Apple Pages, Google Docs, and so on) while allowing the presence of blocks to contextualize content tools. This duality most definitely runs into challenges and tribulations. Do you think the fact you can be at the bottom of a paragraph and press down arrow to move to the next is a problem in itself or something that could possibly be made coherent from your perspective? Notion is an editor that seems to generally adhere to this mixed paradigm as well, curious to know how you might find it behaves? I think it suffers from a lot of accessibility shortcomings, but might be interesting to see how deep it runs.

For some background, when the block-editor project began there were two prototypes in conflict: one used a single contenteditable root while the other encapsulated block function entirely (including sub-contenteditable properties). Some of the expected interactions to be supported were outlined in issue #179. It's important to note both models had blocks implemented and could conceivably be made to work.

The model that technically isolated blocks more was deemed more robust as a foundation (contenteditable is notoriously fragile and idiosyncratic between browsers) but it was never assumed to dictate the entire spectrum of interactions to follow. WritingFlow was developed to try alleviate some of the inherent drawbacks of the chosen direction in the context of what other text editors have established as presumed common interactions.

On top of it, there's also the difference between editing and navigation mode (you could argue writing is also another one to consider), which helps encapsulate some parts of the interaction paradigm. At the same time, modes are inherently problematic for making software that is easy to use, as famously put forwards by Larry Tesler.

I believe that considering diversity in its widest sense, some aspect of modes are necessary to accommodate different behaviours and their optimizations, but it's still worth discussing how we could integrate modes in a more transparent way (based on what you are trying to do) and not as unnecessary complexity. For example, would it make sense to ask a user if they want to switch to navigation mode when they press down arrow at the edge of a paragraph or would we rely on them knowing how to switch modes on their own?

To be crystal clear, I think it's fine to add an option to disable this behaviour completely just to keep things from stagnating, but I'm also curious to see if we can think of ways in which it'd still make sense to switch focus to another block using arrow keys. Thanks for all the feedback!

[MarcoZehe]

I was just reminded of a feature JAWS introduced in 2008 where it tried to become smarter at switching between virtual cursor (browsing) and forms (browser focus) modes. Previously, when filling out forms, you had to arrow to a text box or combo box in website reading mode, then hit Enter to switch to forms mode, fill out form elements, possibly tabbing to others, then press Escape to return to website reading mode and continue browsing or finding other controls to manipulate, possibly reading form text context etc. In JAWS 10, the developers tried to switch to forms mode automatically when virtual cursor hit such a form field, and switch back out of it if the user pressed the up or down arrow key again. This led to a lot of confusion, and JAWS to this day has a feature to turn this off.

NVDA adopted part of this automated mode switching. If using arrow keys, modes would not switch. If using Tab, and focus landed on such an element that forms (or focus) mode would be used, focus mode would be switched on automatically. And off if tabbing off of such an element. So, they adopted a partial model of what JAWS did, and this was more well received by users, since especially arrow keys still behaved predictably and kept you in the text field you were editing. Because this is one of those things the JAWS model suffers from this day: If you are in a textarea and arrow too far in either direction, you drop out of forms mode and have to arrow back in.

Since tabbing in Gutenberg is reserved for moving to the side bar, sort of making the current block modal already when in edit mode, I am not suggesting we change that. Rather, I am showing that making arrow keys behave in such a mode/context switching manner can be really confusing.

[alexstine]

Hello,

I think there is a couple parts to this.

1. I think in no situation should edit mode be able to change blocks. It doesn't really matter how clear the announcement is for screen readers, it is just super bad UX for a block by block layout. You really can't consider Gutenberg to flow like a document because each section is so individualized from another.
2. I think there needs to be more for screen reader users as far as instructions go. As far as nags to ask about changing to navigation mode, no, probably not. This could likely clutter the UI.

Thanks.

[mtias]

It seems a sensible path would be to add this as configuration initially and look at exposing instructions / ability to set configuration in the welcome modal (it could include things like Top Toolbar and other shortcuts as well, which has been discussed before).

[alexstine]

Summary from #accessibility channel meeting.

A new option will be added under "More Tools > Options" to toggle writing flow. Still trying to decide how the option text should read and what a suitable description might look like. Full conversation below.

Conversation

afercia  11:39 AM
Recap from https://wordpress.slack.com/archives/C02RP4X03/p1589558927263200
11:40
We were arrived at:
So at the very, very, least I’d like to propose an option to completely disable WritingFlow. Optionally, consider to remove it from Editr mode by default.
nrqsnchz  11:41 AM
I’d like to propose an option to completely disable WritingFlow
How would this look like? A setting or option you can turn on/off? (edited) 
afercia  11:42 AM
A user option to turn it off.
nrqsnchz  11:42 AM
I think that could be a good balance
afercia  11:43 AM
Could be communicated as something similar  to Firefox’s “Caret browsing” 🙂 Little known Firefox feature that can be activated by pressing F7
nrqsnchz  11:43 AM
where would a setting like that live? In the ‘More Options and Tools’ menu?
11:43
I did not know that was a Firefox feature!
afercia  11:43 AM
Sounds like the most logical place. At one condition: I don’t want the option to me communicated as related to accessibility only.
11:44
I see the option as a general feature that can benefit any users that just don’t like WritingFlow.
joedolson  11:44 AM
How would it be conveyed to the user what they were disabling by turning off "WritingFlow"? Conceptually, that phrase conveys no information to me about what it does.
jeryj  11:45 AM
Same here. I’ve been wondering what that setting would be called.
afercia  11:45 AM
Screenshot 2020-05-22 at 17.45.11.png Expand file
React with 100 emoji
11:45
@joedolson something like the above
11:46
“a moveable cursor in the content area” explains it in the most reasonable way. (edited) 
nrqsnchz  11:47 AM
I just turned caret browsing on and I’m loving it
joedolson  11:47 AM
👍
afercia  11:47 AM
@nrqsnchz aha yeah that’s why it needs to be a user option 😉 (edited)
alexstine  11:48 AM
👋 A movable cursor really doesn't fully describe the option, it needs to communicate the ability to move cursor from block to block while in edit mode. Maybe even a toggle button to enable/disable Writing Flow with a link to describe what Writing Flow does. It seems like a fairly hard to explain concept, maybe best to convey in docs.
nrqsnchz  11:49 AM
Hi @alexstine!
joedolson  11:49 AM
I think it's OK if the option description isn't a perfect description, especially if it includes a link to documentation. I just feel that if it just said "Disable WritingFlow" that would be utterly mysterious to the user.
afercia  11:49 AM
Hey @alexstine I was thinking to use “moveable cursor” for the description. The option name would need a better text.
11:50
I’d agree on documentation, which leads me to one more point for later during open floor.
nrqsnchz  11:50 AM
Agreed, we can fine tune and iterate on the wording. But I believe we’re all in agreement of creating this option is a good path forward?
alexstine  11:51 AM
I think that would be best. Leave the choice up to the users.
React with +1 emoji
joedolson  11:51 AM
"Choices, not decisions"
11:51
😉
afercia  11:51 AM
As I said, at the very least there should be an option to disable / enable WritingFlow.
I won’t waste my time in discussing what the default should be, as defaults in WordPress are lately subject to changes for undocumented reasons.
React with bomb emoji
nrqsnchz  11:52 AM
Will anyone like to help summarize this discussion and add it the GitHub issue?
alexstine  11:53 AM
I can summarize later today. Will need some help making adjustments to PR, not quite ready yet for making new options I think...
nrqsnchz  11:54 AM
Thanks @alexstine! I’m sure we can ask for help and figure that out.
afercia  11:54 AM
@alexstine if we go for a user option I think the best thing would be to start a new PR
alexstine  11:55 AM
Agreed. Easier to track feedback this way on code.

End Conversation

A new pull request needs to be created with support for an option.

Thanks, Alex