Moving blocks via keyboard: screen readers don't notify operation done

[talksina]

Short description:

When using a screen reader, it's not possible to know if blocks have moved up and down, using Gutenberg's keyboard shortcuts ctrl+alt+shift+t -move up-, and ctrl+alt+shift+y -move down-

When it works

If a block is moved up and down using arrows, the "move up" and "move down" buttons on blocks toolbar, screen reader correctly announces "block moved from position x to position y".
But to reach the toolbar I'm forced to move the focus away from editing mode, with alt+f10 then navigate to arrows, then move back to editor.

Steps to reproduce

1. open a blank post or page, then add some blocks
2. focus on the second block. Both navigation and editing mode are affected by the issue.
3. try to press ctrl+alt+shift+t to move the block upwards one position. Then ctrl+alt+shift+y to move it back in its original place.
4. Screen reader - tried Jaws, VoiceOver and NVDA- give no feedback about the block's movement.

Expected results:

When pressing ctrl+alt+shift+t or ctrl+alt+shift+y on a block to move it, both in navigation and editing mode, screen reader should announce if the block has moved and where, like it does when I use the arrows.

Current results

When pressing ctrl+alt+shift+t or ctrl+alt+shift+y on a block to move it, both in navigation and editing mode, screen reader does not announce if the block has moved and where. It stays silent, and I'm forced to double-check whether or not the blocks have been moved.

WordPress and Gutenberg versions

It was present in 17.x branch and persists in latest 18.2.0 build. WordPress 6.5.2 is used.

[talksina]

Update:
when you are in navigation mode, the screen reader announces the block line. That is: if you move a block from row 6 to 5 with ctrl+alt+shift+t or from 5 to 6 with ctrl+alt+shift+y, it says "block: group, row 6" for example. But does not say that the block has moved from a row to another, as it does when you use the arrows.

[talksina]

This should be fixed ASAP! It allows to move blocks back and forth when needed, without distraction. But if screen reader doesn't warn about the change like it does when you move a block via its toolbar, it is a big trouble especially when using Full Site Editing.

[talksina]

19.1 gutenberg and it's not fixed yet - please mention me if there are any news.

[t-hamano]

Hi @talksina,

We are trying to fix this issue in #64966, but first I wanted to make sure the current announcement of the block mover button is correct.

I use NVDA, and in my testing, the block mover button doesn't announce that a block has been moved. Additionally, the screen reader announcement seems to be delayed by one.

1. For example, insert multiple Paragraph blocks inside a Group block.
2. Select the first Paragraph block.
3. Use the keyboard to focus on the "Move down" button on the block toolbar. My screen reader reads the following, , which seems to be the description of the previously focused element, i.e. the "Move up" button:

   Block Paragraph is at the beginning of the content and can’t be moved up
   Move down  button
   Move down
   

4. Press the Enter key to move the first Paragraph block down one level. My screen reader reads the following, which seems like a description for the Move down button itself, and doesn't notify me that the block has been "moved.":

   Move Paragraph block from position 2 down to position 3
   

I'd be grateful if you could let me know if this behavior is different from your screen reader.

[talksina]

Hi, I have JAWS for Windows, latest 2024 build. And Gutenberg I have the stable 6.6.2 release as the latest 19.3.x build has the #65267 bug which prevents me from writing. So, I am testing the instruction you asked me. and it is actually bugged: latest Gutenberg editor -19.3.0 build- reads the current button's label only, then the description of the previous. You found a bug I didn't even notice... I suppose I have to open another issue, I'll mention you Confirming this, I'll open another bug report then mention you - I didn't notice it because I am currently using the 18.x branch because of another regression 19.2 brought up. I can't exclude it could be originated by the same modification that caused the #65267 one!

[talksina]

Let me mention @afercia - as the bug @t-hamano mentioned regards selection and abnormal behaviour in selecting first element, maybe it's a consequence of #65267 issue which should have been reverted now, but I have not possibility to test it yet.

[t-hamano]

Thanks for testing.

I noticed that the issue of screen readers reading the description of the previously focused element did not occur in WordPress 6.6. This means that this issue occurred in Gutenberg, which was released after WordPress 6.6, i.e. Gutenberg 18.6 or later.

I would like to find out whether this issue is the result of #65267 or another commit.

[talksina]

I started to have selection issues in Gutenberg 19.2 branch, I currently use WordPress 6.6.2 stable with its built-in gutenberg block editor. I downgraded deactivating the newest plugin when 19.2 came out, because it didn't speak when selecting even characters in block - issue 65267 I mentioned.

[afercia]

I use NVDA, and in my testing, the block mover button doesn't announce that a block has been moved.

I'm not sure there's ever been an audible message to confirm a block has been moved.

I created #23995 in June 2020, that is more than 4 years ago, to add such a message and there is a PR proposed. I think it never landed because of disagreement on the implementation.

That said, testing with Safari and VoiceOver, the description of the buttons may not be in sync with the actual block position but I couldn't reproduce it consistently. It's definitely buggy in some condirions.

I seem to understand there is some understandable confusion about the announcement, let me try to clarify.
There is no confirmation message in all cases.

• When using the keyboard shortcuts, screen readers don't announce anything.
• When using the buttons in the block toolbar the block rerenders. As such, browsers and consequently screen readers 'think' that focus landed on a new element and they announce the mover button again, including its description with the position information. The position information might be not timely updated or the screen reader may not get the update and announce the previous description.

In the scenario above when using button the screen reader announcement is not a confirmation message. It's just the button description that gets announced again e.g. Move Paragraph block from position 4 down to position 5.

This could be solved by implementing an audibel confirmation message with assertive politeness, which would intgerrupt any other announcement. See https://github.com/WordPress/gutenberg/pull/24894/files

Additional problem with the button tooltip

The mover buttons description is meant to provide information on the current block position and where it will be moved when using the buttons. The aria-describedby attribute of the buttons points to a visually hidden element with the related information. Example screenshot:

However, when the mover button is hovered or focused, its tooltip is rendered. At this point, the aria-describedby attribute value updates and points to the tooltip instead. Example screenshot:

The information about the position and action is completelyt lost and the description just repeates the accessible name e.g. 'Move down'.
I already reported a few times that this is a wrong implementation that comes from the Ariakit tooltip. Tooltips should never be references by aria-describedby. This is wrong and needs to be fixed. Cc @WordPress/gutenberg-components

[ciampo]

The information about the position and action is completelyt lost and the description just repeates the accessible name e.g. 'Move down'.
I already reported a few times that this is a wrong implementation that comes from the Ariakit tooltip. Tooltips should never be references by aria-describedby. This is wrong and needs to be fixed.

Thank you for the report — this is being actively discussed in #65888

[afercia]

Thank you for the report — this is being actively discussed in #65888

Actually, the new tooltips implementation has been reported as incorrect in many other previous issues.