Size Change: +71 B (0%)

Total Size: 1.16 MB

_{compressed-size-action}

Sorry about that.

@tellthemachines It was necessary to use the dialog because of the tabbing issues. Remember, for Windows users, Tab and Shift+Tab are primary navigation keys unlike the majority of cases on Mac with Voiceover. If there is some other approach that would allow us to get the same results of a dialog without using a dialog, that would be great. There are a ton of libraries at play in block-list though and it will be tough to figure out how to solve this without breaking it further. Essentially what needs to happen is this.

#37965

The only difference being we need to only focus the Sidebar when there is no more focusable element in the block content. This could get tricky though playing around with focus which is why I actually do like the dialog better but I understand how intrusive it is.

My thoughts:

1. Insert a Columns Block.
2. Columns Block is presented as an application instead of document.
3. Add aria-labelledby for Columns title and aria-describedby for any needed descriptions.
4. Focus is placed on first Block Variation.
5. At this point, Shift+Tab should focus the Block Toolbar since there is no previous focusable element within the current content.
6. Tab should continue through the Block Variations until it reaches the last focusable element in the content, then it should land on Block Sidebar.

Any of this sounding reasonable? It just sounds insane to have to mess with focus like this.

It was necessary to use the dialog because of the tabbing issues. Remember, for Windows users, Tab and Shift+Tab are primary navigation keys unlike the majority of cases on Mac with Voiceover.

I'm not sure I've got this 100%, so to clarify: do we want to move focus into the block placeholder with the Tab key, when a new block is inserted? Currently, when inserting a Columns block, focus moves to the whole block, and then we have to press Down Arrow in order to access the buttons inside. But once inside, all the controls can be navigated with Tab.

Would focusing the first focusable element in the block after insertion solve the problem? Plus adding semantic markup so the block heading and description are read out, of course.

Whatever we decide on, the solution should work for all blocks that have placeholders: Navigation, Cover, Image, Gallery, Table, etc. so ideally it should be a global change in the placeholder, as opposed to individual changes for each block.

@tellthemachines Oh no, I forgot to test this.

So, you are correct in one case.

1. Insert a Columns Block.
2. Down Arrow will focus the Block Variations.
3. In theory, we should automatically focus the placeholder.

Here is the problem I am seeing.

1. Select Options > Preferences.
2. Select Blocks.
3. Enable Contain text cursor inside block.
4. Close the dialog and Options menu.
5. Insert a Columns Block.
6. Notice how pressing Down Arrow does not focus the Block Variations panel and how focus jumps directly to the Block Settings Sidebar.

Sorry for not being more clear about this, but it works differently based on that setting. We've got to have this working the same way across the board.

Thanks.

It almost seems like Writing Flow is allowing some type of focus switching and whenever Writing Flow is disabled for switching from Block to Block, this is why it breaks.

Oooh, I should have thought to test it with the "Contain text cursor inside block" setting! It makes sense that Arrow key navigation wouldn't work with that setting enabled.

I'm thinking ultimately the only way we can make things work properly is making the whole editor content navigable with Tab. But perhaps to start with, we can make it so the block placeholder buttons can be accessed with Tab instead of Down Arrow.

@tellthemachines I just pushed a fix which should help with this. Thoughts? I tested with Columns and Navigation Blocks and Tab works fine now. I also gave the Paragraph Block a test just to ensure this didn't break existing functionality. Finally, refreshed the PR with latest commits.

This was a much easier solution, wish I had thought of this earlier.

Thanks.

@ellatrix I have implemented the E2E tests. Does this help you understand what is going on?

BTW, this is the first couple E2E tests I've added so still learning... It is an interesting mindset to take a step back and mock how your functionality should work.

I'm mostly AFK until Thursday, but would like to review this before merge. I'll try to do it today or tomorrow or otherwise Thursday.

@andrewserong In theory, it should be possible. The only thing I never liked about this method of removing a block is focus gets super lost so this may give us a good opportunity to fix both issues.

1. Allow Backspace key to remove the block even if not on block wrapper for non-content editable blocks.
2. On block removal, make sure focus is dropped in a place that makes sense instead of leaving screen reader users in the void.