Description

The Block Bindings API, which gives users the ability to connect block attributes to values obtained from different sources, was recently introduced. It also powers Synced Pattern Overrides.

As part of the UX around this new feature set, we've disabled editing of connected block attributes as seen in the following PRs:

• Block Bindings: Disable editing of bound block attributes in editor UI #58085
• Patterns: edit source pattern in focus mode in post and site editors #57036

However, while testing accessibility via keyboard navigation and NVDA in Windows Firefox, I realized that these read-only attributes are not announced as non-editable by screen readers — in other words, they are not announced as different from normal block attributes in any way.

As a result, if users attempt to edit these fields or expect to see them as editable like in normal blocks, the current keyboard behavior either sends them entirely out of context with no indication or skips over the fields entirely, likely causing confusion.

Here follow some ideas on how we can improve this and related UX around the Block Bindings:

1. Regarding patterns specifically, I found navigating to the actual editable content in a pattern using a keyboard to be unintuitive and inconsistent. We should consider improving this flow by ensuring content is readable in the sidebars so users know what it is they'll be editing, as well as adding non-editable content to the sidebars so users can have proper context, and distinguishing between the editable and non-editable fields. We should also consider what the best tabbing behavior should be when in Edit Mode. Note: This may be a broader issue regarding the interplay of Navigation Mode and Edit Mode.

2. In both of these modes, it'd be good to announce to users when fields are non-editable.

3. Additionally, when users press Enter on read-only block attributes in pattern instances, namely paragraph or heading content, normally this would activate Edit Mode but this currently unexpectedly sets focus elsewhere and causes context to be lost; when doing this with other kinds of block bindings, the resulting behavior is similarly unexpected. We should aim to handle these scenarios gracefully in a way that doesn't cause users to lose context.

4. For disabled fields like image alt, since users may be expecting to see them as editable in the block settings like in normal blocks, we should announce that those fields are read-only rather than skipping over them when using tab navigation.

5. Somewhat related to the above, how one should edit the content of a buttons block just using the keyboard was unclear to me. If this is indeed an issue, we can take that into account when determining any improvements to make, either as part of an overall fix or coordinating with another fix that may be in progress.

Note: This was first raised in the following comment.

Step-by-step reproduction instructions

Patterns

Setup

1. Add a new synced pattern
2. Add 2 headings, 2 paragraphs, 2 images, and 2 buttons blocks
3. Under Advanced, enable pattern overrides for one of each kind of block
4. Save the pattern

Testing Pattern Overrides with a Keyboard and Screenreader

1. In a new post, add the patten
2. Using keyboard and a screenreader, tab until you reach the pattern
3. Press Enter to go into Edit Mode
4. Tab a few times to reach the editable content — see that the screen reader doesn't announce what the content of the pattern is, so it's hard to know what one would be editing
5. Now press Enter to edit one of the blocks, then press Escape twice to enter Navigation Mode
6. Tab to a non-editable block, and press Enter to switch to Edit Mode — see that focus and context are lost
7. Tab until you reach the editable pattern content again
8. Press Enter on one of the editable fields, then tab away from the field — consider what the expected behavior should be in this scenario

I only go through the heading and paragraph block in the video above, but similar UX inconsistencies are present on the image and button blocks.

Other Bindings

Setup

1. Register a new custom field however you prefer, for example the following code in your theme's functions.php:

register_meta(
	'post',
	'text_custom_field',
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
		'default'	   => 'This is the content of the text custom field',
	)
);
register_meta(
	'post',
	'url_custom_field',
	array(
		'show_in_rest' => true,
		'single'       => true,
		'type'         => 'string',
		'default'	   => 'https://wpmovies.dev/wp-content/uploads/2023/04/goncharov-poster-original-1-682x1024.jpeg',
	)
);

2. Create a new post, open the code editor, and insert the following:

Note: This functionality appears to not be working for headings, images, and buttons on trunk at the moment, so I've omitted them from these testing instructions for now.

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"url_custom_field"}}}}} -->
<p>Overridable paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Regular paragraph</p>
<!-- /wp:paragraph -->

3. Open the visual editor and navigate to the page content using a screenreader
4. Tab to a normal block and press Enter to use Edit Mode
5. Press Escape twice to use Navigation Mode
6. As you tab using Navigation Mode, notice that bound blocks are locked visually but screen readers don't announce them as non-editable
7. Press Enter on a bound block to enter Edit Mode, then start typing
8. See that the field is not announced as non-editable

Here's a video reviewing the overall UX when navigating with keyboard and screen reader across bound blocks. As mentioned, the heading, image, and button blocks appear to not be working consistently at the time of this writing so you may not be able to see that specifically, but we should still be able to get this discussion started:

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