Block Bindings: Improve accessibility for non-editable, bound fields

[artemiomorales]

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

creating-pattern-v2.mp4

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

editing-pattern.mp4

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:

accessibility-disabled-fields.mp4

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

[artemiomorales]

Note: Block Bindings appear to not be working for me consistently for headings, images, and buttons for now on trunk, so I've omitted them in the testing instructions for Other Block Bindings for now.

[artemiomorales]

Pinging @joedolson @afercia @andrewhayward for your thoughts on best practices regarding accessibility here, and to add any context regarding navigating Gutenberg with keyboard and screen readers that I may be missing.

Do these proposals that I have above sound reasonable, or is there anything else we should be considering to improve the UX of keyboard + screen reader navigation?

[afercia]

@artemiomorales thank you for creating this issue, for the very detailed explanation (which I know takes a lot of time) and more importantly for caring about accessibility ❤️

It's a pretty complex issue to read through and test, it will take some time.

[artemiomorales]

@afercia Of course, thanks to you for taking a look! Just let me know if you'd like any clarification or woudl like to discuss anything more in depth 😄

[annezazu]

Want to ping @alexstine here as well in case he can dig in. Thanks for making this 🙌🏼

[afercia]

I started testing the bound block following instructions from WordPress/wordpress-develop#5888 and have some initial thoughts, limited to semantics so far. Keyboard interaction will need more testing.

contenteditable-based blocks

Blocks that are based on contenteditable, for example Paragraphs and Headings, should communicate they cannot be edited in the most possible native way.

I see that when a Paragraph or Heaeding take their content from a bound source, their contenteditable attribute gets a false value. So far, so good. An aria-readonly="true" attribute would semantically communicate the block cannot be edited.

However, we need to solve another, long standing, issue. Some of the contenteditable blocks have an ARIA role="document". That was changed from the original role="textbox" to solve an issue with the JAWS screen reader. That change has been discussed at length in another issue (can't find it right now) and there's no agreement about it. Personally, I'm not sure deviating from the specifications to solve very specific issues with very specific software is ideal. Ib my experiences, this kind of approach leads to more harm than good an over time, inevitably, turns to be incompatible with new features and needs. I think I expressed more in details why that change should be reverted in the other issue.

That said, we now need to communicate a contenteditable is read-only. To do it in an appropriate way, we need to first communicate the contenteditable is a textbox and not a document.

More holistically, I'd think that whenever a contenteditable value is false, the editor should also set an aria-readonly="true" attribute. The resulting relevant attributes for a bound contenteditable-based block that cannot be edited should be:

contenteditable="false" role="textbox" aria-readonly="true" with the addition of aria-multiline="true" when a block accepts text in multiple rows.

Other blocks

Other block that aren't based on contenteditable should do something different. The Image block, for example. I have no great ideas on how to communicate an image can't be edited or that its alt attribute can't be edited.

Suggestions welcome. I'd tend to think there should be some labeling or announcement at the block container level, to inform users the block, or some of its attributes, cannot be edited.

Visually

RIght now, there's no visual indication that a bound block cannot be edited. That can be inferred from the block toolbar, as some controls are not available for bound blocks. I don't think that's sufficient though. See the screenshot below where the first Paragraph is normally editable and the second Paragraph can't be edited. They look identical. I'd think there should be a clear visual indication, in addition to a semantic indication.

Adding the needs design feedback label.

Cc @joedolson @alexstine @andrewhayward

[afercia]

Re: the visual feedback may better discussed in a separate ticket. I'd just like to add that I can't see anything in the UI that tells me, for example, a Paragraph content can't be edited besides the fact the block toolbar shows less controls. I can't see anything in the List View and anything in the Settings panel either. Images with a connected al attribute at least show a descriptive text 'Connected to a custom field'. Other blocks don't show anything.