Components: `Placeholder` `instructions` prop spoken message can be too regular and incorrectly take precedence over other spoken messages

[talldan]

Description

The Placeholder component's instructions prop triggers whenever the component mounts and the instructions are defined, and this can be a little bit too much, causing it to take precedence over other messages or be announced very unexpectedly:

gutenberg/packages/components/src/placeholder/index.tsx

Lines 82 to 86 in 27fbbd8

	useEffect( () => {
	if ( instructions ) {
	speak( instructions );
	}
	}, [ instructions ] );

For example, the message can be triggered when:

• loading a post
• switching between code and visual editor modes (in this case there's also supposed to be a spoken message about switching modes, but it gets clobbered by the placeholder because every time speak is called the current spoken messages are cleared)
• A pattern containing those blocks is inserted

If you have multiple blocks in a post in placeholder state they can also all try speaking at once, which is very impolite.

Feels to me like this prop doesn't work in the right way. The instructions should probably only be read when the block is interacted with (selected?) and even then some care needs to be taken to ensure it only happens infrequently preferably on the first interaction. I'd question whether a spoken message is the right option at all as I think they're best for providing feedback about a current user action, but it'd be good to get further accessibility feedback on that.

Step-by-step reproduction instructions

1. Insert a group block into a post and leave it in the placeholder state
2. In the Editor options menu, switch to Code Editor mode
3. Switch back to Visual editor mode

Note that the spoken message for switching back to Visual Editor mode is never announced and the assertive aria-live region is empty. The group block's instructions can be announced even though they're polite` and not currently being interacted with.

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

[joedolson]

Without testing, I would say that your instinct is right: spoken messages should only occur on interaction. I find it hard to see a good reason to announce these instructions at any time other than when a user is interacting with it.

I think this would benefit from some close reading of #45801; there's a lot of discussion of the implementation this required. But I agree this might require some new addressing - perhaps the original proposal by @afercia would now work with Windows screen readers? Worth testing, anyway. But if these messages are overriding other important announcements, that's a problem.

@alexstine Also pinging you in case you want to take a new look at this.

[alexstine]

@talldan The main problem is, these Placeholder messages are only read on block render via useEffect. If we could create some type of dynamic block watcher to announce state changes, I think that's probably the most full proof solution. Block render is not the same thing as block select or any type of state change that happens within the block. Surely there is a way to create a generic hook to listen for these.

[joedolson]

Testing this today using Chrome/NVDA, I did not find the same issue; while the placeholder block is still quite aggressive at announcing, it did not override the editor switched message.

Re:

Note that the spoken message for switching back to Visual Editor mode is never announced and the assertive aria-live region is empty. The group block's instructions can be announced even though they're polite` and not currently being interacted with.

In my test, the spoken message for switching back to the visual editor was announced, and then the Group block instructions were announced immediately after that.

What environment were you testing this in, @talldan?