Announce to screen readers when blocks are moved

[afercia]

Description

See:
#61168
#64966
#23995
#24894

When blocks are moved to a new position either by clicking the mover buttons or by using keyboard shortcuts, sighted users can see the visual change in the editor canvas. Screen reader users with no vision need an audible message to confirm a block has been moved correctly.

At the moment, this is implemented only partially and can be improved. Findings:

1
Using the mover buttons in the block toolbar.
There's no confirmation message at all. A previous attempt was made on #23995 / #24894 but it was never merged and the codebase has largely changed since then.

The mover buttons do have a description with the initial position information that gets updated after blocks get moved. However, there's no confirmation message.

2
Using the keyboard shortcuts
Note: check the 'Keyboard shortcuts' modal dialog to know which ones to use, they are different depending on the operating system in use.

A confirmation message was added in #64966. However, there's no information about the initial and / or final position. When users use these keyboard shortcuts it's likely they are not focusing the mover buttons, which is the only place that provides such information.

Also, it appears these keyboard shortcuts callbacks are triggered also when the block cannot be moved because it's first, last, or the only block in the canvas.

3
Evaluate whether the confirmation message should also provide information about the new position. At the moment, it only announces {number} block(s) moved.. It's worth reminding blocks can be moved vertically and horizontally so that a check for Right To Left languages would be necessary to provide meaningful messages.

Step-by-step reproduction instructions

• Edit a post that contains more than one block,
• Use a screen reader e.g. Safari + VoiceOver or observe the aria-live regions at the end of the DOM in your browser dev tools inspector.
• Select a block and click the 'Move up' or 'Move down' buttons.
• Observe there's no confirmation message after a block has been moved.
• Same for block horizontally nested within a parent block.
• Select a block and use the keyboard shortcuts. On macOS:
  • Shift + Option + Command + Y to move down.
  • Shift + Option + Command + T to move up.
• Observe an audible message '1 Block moved` is announced.
• Select more than one block and repeat.
• Observe an audible message '(number of blocks) Blocks moved` is announced.
• Observe the message doesn't provide information about the new position.
• Select the first block in the canvas, or the last one, or a block that is the only block in the canvas.
• Use the keyboard shortcuts.
• Observe the message is announced anyways even though the block cannot be moved because it's already first, last, or the only block in the canvas.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[t-hamano]

Thanks for summarizing the issue.

The ideal behavior here would be to be notified in detail which block was moved from which position to which position, both when the mover button is pressed and when the shortcut is executed, right?

cc @alexstine @talksina

[afercia]

Looking into this, I'm wondering what the best 'rchitectural' approach would be.

To my understanding, the action to move blocks is here and it is used for both the mover buttons and the keyboard shortcuts, for single selection and multipel selection, for horizontal or vertical blocks as well.

Triggering an audibel message hooking into that action would probably be a more centralized, reliable implementation.

On the other hand, I'm not sure triggering such sort of 'side effects' from actions is a best practice. I genuinely don't know if it;s an acceptable pattern but it is worth noting there are already many cases where 'side effects' are called from various packages actions.js files. For example some calls to speak are already in place in the block-editor actions.js here and here. A couple cases of Notices that also trigger a speak message are here and here. Not to mention the several calls to similar side effects in other packages actions like creating notices via createSuccessNotice, createInfoNotice, createErrorNotice, createWarningNotice.

Cc @WordPress/gutenberg-core for any thougths about the best approach.

[youknowriad]

I think "side effects" in actions is fine but we need to be aware of that this is going to be called for all usage of the action, including programmatic usage by third-party developers..