Writing flow: Try arrow press confirmation before switching blocks #51027
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…irection a second time, useArrowNav.
alexstine
added
[Type] Enhancement
alexstine
requested review from
aristath,
talldan,
afercia,
joedolson and
tellthemachines
|
Size Change: +23 B (0%) Total Size: 1.42 MB
ℹ️ View Unchanged
|
|
Hi Alex! What happens in other editors when a column is entirely |
|
@ellatrix I have actually never seen another editor like this. The problem here is sighted users have the benefit of seeing when the cursor is at the edge of the block and screen readers do not get the same information. Slack's solution for this with their compose message field was to simply require another arrow press that way screen reader users know that they are at the edge since blind users do not get this information. It is highly disruptive to switch blocks when a user does not know they are at the edge. Also, note that screen readers read line by line with arrow keys up and down and character by character with arrows left and right. Something as simple as checking for a period at the end of a paragraph block would be tricky on Mac due to not having a super defined "end" key like most Windows laptops have. I'm just speaking from experience on my 2018 Mac. I much prefer Windows keyboards as they are easier layouts under most circumstances. Anyway, the same issue applies to Mac and Windows that up and down arrow keys do read by line. Eventually, the paragraph block will need to wrap text so using up and down arrow keys is a much faster way to read blocks content. I am not saying this should go straight into trunk, we could likely hide it behind a setting. I was just trying to model this after what another big company has done and after some getting used to, it actually works really well. I am not sure if this is publically documented though. I may go ask the Slack Accessibility team to do a blog write-up about this one. Thanks. |
|
@alexstine No worries, I'm just being curious here! :) Two questions:
|
|
@ellatrix Answers.
Navigating block by block is slower overall due to the focus transitions when in a normal text field, vertical navigation is much quicker. That is why I've always said arrow keys to switch blocks can be rather jarring for us specifically... |
|
This is needed. I regularly face the issue of moving to another block and if the text is not clear, it is confusing. I will test what is suggested and ask others too who use screenreaders too, and ask for help to document it. Thank you for working to fix this. |
|
In principle, I like this - I think it could really help some of the unpredictability issues with moving from block to block unexpectedly. In your todos, you say 'Currently, the local variable is not set to false if you move away from the vertical or horizontal edge. Trying to figure out how to solve that.' So I'm clear, you mean that edgeHasFocus doesn't get changed from true to false if you're on the bottom edge, and press the up arrow. Is that what you meant? Can you use |
|
@joedolson Sorry, I think I fixed the variable issue. To check if a block is empty, I need to use a selector I think. Just not sure which one in block-editor will get me what I need. I know we have selectors around if the whole post is empty but not a specific block. The other thing I need to test is making sure this hasn't broken block selection. I may try to write a writing flow E2E test so people can at least see what I am trying to accomplish here. Then we'll be able to catch bugs if the new test fails. I'll be back to work on this eventually. Thanks. |
…ng-flow-confirm-arrow-press
|
Flaky tests detected in b128fd3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5338656261
|
|
I don't mind this if it either replaces the current keep-caret-in-block option, or it becomes a new option. We can't do this as the default experience because this is not what editors normally behave like (TinyMCE, Google Docs etc.) I think we could be better at arrow key navigation over more complex blocks though. |
15 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
The PR changes writing flow to require a confirmation arrow key press after reaching the border of a block to switch blocks.
Why?
This has been a long time hated feature for me because as a screen reader user, it is not always apparent when I am at the edge of a block and my next arrow press sends me into another block with no warning. From that, a setting was added to restrict this behavior. Eventually, Slack Accessibility team tried something new. If the Slack composer field for a DM or channel contains text, you can navigate to the top of the field on Windows by pressing up arrow or ctrl+home. However, once you finally reach the top of the field, you must press up arrow another time to confirm that you wish to leave the compose field and enter the DM/channel message list. I figured, why not start a draft PR and play around with it for the block editor. It was not hard to get an initial POC, all I need now is the community to be a little open minded as this could make the experience better for everyone.
It is worth saying that this might still not be enough in the end to make the experience as unified for screen reader users as it is for the sighted, but maybe it could be a good first step.
How?
Essentially, I am just tracking this within a variable that is true or false depending on certain conditions. This is all hooked up in
useArrowNav()writing flow hook.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
To-do: