-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Bindings: Improve accessibility for non-editable, bound fields #58595
Comments
Note: Block Bindings appear to not be working for me consistently for headings, images, and buttons for now on |
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? |
@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. |
@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 😄 |
Want to ping @alexstine here as well in case he can dig in. Thanks for making this 🙌🏼 |
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 blocksBlocks that are based on I see that when a Paragraph or Heaeding take their content from a bound source, their However, we need to solve another, long standing, issue. Some of the contenteditable blocks have an ARIA 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 More holistically, I'd think that whenever a contenteditable value is
Other blocksOther 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. VisuallyRIght 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. |
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. |
@afercia Great, thank you for taking a look at this and offering your recommendations so far 🙏
While it seems the
|
@artemiomorales Please could I ask you to provide an update on this one? It seems that
Are these points something we feel we will still be able to target for the 6.5 release? Did I miss anything out or any work that has been complete I am unaware of? I don't see the |
You're right that visual feedback is doable and we're adding some indicators here via input from design.
It looks like we likely won't be able to improve the accessibility with screen readers for 6.5, and that yes this is a larger discussion on how to improve the overall flow when editing documents, encountering noneditable fields, and switching between Navigation and Edit modes that will require more discussion. |
There is a lot of discussion here. The document role was introduced as I was trying to fix a very specific JAWS accessibility bug. Although, the role used before it, group, was also not correct. I accept responsibility for making the situation worse with the document role but never did figure out who added the group role and why. I think at this point, now that all the tests are playwright, changing to textbox is probably something to play with. Textbox role for text blocks, switch back to the group role for non-text blocks. My point, there should have never been a specific role added to |
OK thanks for confirming folks. @fabiankaegy @annezazu for your information re: WP 6.5:
|
I'm removing this from the 6.5 board as we are entering RC period for WP 6.5 the only immediately actionable task has been completed. |
Can we get an update on what's remaining on this issue? It seems like it's been suspended to address the larger navigation issue, but I'm not totally clear what steps are being taken. If there isn't any new accessibility feedback needed on this issue, we could remove the Needs Accessibility Feedback label. |
1 There's already a long standing issue for this, see #42158. 2 3 4 |
Anyone willing to test the user interface with bound blocks can use the following snippets. As of April 2024 this will add 2 bound Paragraphs, one bound Image, and one bound Button. Note that the button appears to be a bit buggy. Hoping this can help accessibility and usability specialists to test the UI Cc @joedolson @alexstine Register a few post meta by adding this snippet to your theme's functions.phpadd_action( 'init', 'test_block_bindings' );
function test_block_bindings() {
register_meta(
'post',
'text_from_meta_ui',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'wp_strip_all_tags',
'default' => 'default text from registered meta',
)
);
register_meta(
'post',
'text_from_meta_long',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'wp_strip_all_tags',
'default' => 'longer text from registered meta: A wonderful serenity has taken possession of my entire soul, like these sweet mornings of spring which I enjoy with my whole heart. I am alone, and feel the charm of existence in this spot, which was created for the bliss of souls like mine. I am so happy, my dear friend, so absorbed in the exquisite sense of mere tranquil existence, that I neglect my talents. I should be incapable of drawing a single stroke at the present moment; and yet I feel that I never was a greater artist than now.',
)
);
register_meta(
'post',
'url_from_meta_value',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'esc_url_raw',
'default' => 'https://wpmovies.dev/wp-content/uploads/2023/04/goncharov-poster-original-1-682x1024.jpeg',
)
);
register_meta(
'post',
'image_alt_from_meta_value',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'wp_strip_all_tags',
'default' => 'some meaningful alt text',
)
);
register_meta(
'post',
'image_title_from_meta_value',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'wp_strip_all_tags',
'default' => 'some meaningful title text',
)
);
register_meta(
'post',
'button_text_from_meta_value',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'wp_strip_all_tags',
'default' => 'This is the bound button text',
)
);
register_meta(
'post',
'button_url_from_meta_value',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'esc_url_raw',
'default' => 'https://wordpress.org',
)
);
register_meta(
'post',
'button_linkTarget_from_meta_value',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'wp_strip_all_tags',
'default' => 'hello',
)
);
register_meta(
'post',
'button_rel_from_meta_value',
array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
'sanitize_callback' => 'wp_strip_all_tags',
'default' => 'lalala',
)
);
} Blocks to add to your post content via the Code editor mode
|
This seems beyond the scope of Block Bindings specifically, but maybe this project is the impetus that will drive a revision of these roles and the keyboard navigation overall. It seems like a big lift and I feel a bit stuck on the topic. I think we'd need to reach some agreement on the best path forward, then commit to gradual transition to ensure consistency across the editor, right?
Rather than simply disabling the fields, can we leave them enabled and focusable but introduce an aria label to better indicate to users their behavior, that they're disabled due to the binding but can be edited if the binding is removed?
The aim is to revisit this UI for 6.6, so we can take these ideas into consideration as we iterate on and improve the UX. Thank you 🙏 CC'ing @SantosGuillamot @SaxonF regarding this point on the UI. |
|
For anyone following along, regarding the following two points...
...a few proposals to improve the Block Bindings UX have been introduced in the following comment:
I'm currently experimenting with the first item, and speaking with @jasmussen, one idea is to remove the visual indicator in the block toolbar altogether and just focus on these three proposals above for now. @afercia, I've pinged you on #61404 to get your thoughts 🙏 The scope of this overall issue is also a bit big and unwieldy, so I'm thinking to close it and instead focus the discussion on these smaller issues, and/or open new ones, that correspond more directly to steps on improving accessibility that are actionable within the scope of Block Bindings. |
Hi folks, |
I was reading through this conversation again and it is not clear to me the actionable items. There have been a bunch of changes trying to improve the UX of block bindings, so I am not sure which ones remain relevant either. It'd be great to revisit them and potentially create separate issues. I feel that having smaller scopes could help pushing any fixes forward. |
@SantosGuillamot Ok I've reviewed the cases above and many of them have been solved due to 1.) synced pattern overridable blocks now requiring a name, and 2.) the enabling of editing for bound fields. I did encounter two new bugs as a result of the changes, though:
With that in mind, I'll go ahead and close this issue. Thanks! |
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:
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:
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.
In both of these modes, it'd be good to announce to users when fields are non-editable.
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.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.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
creating-pattern-v2.mp4
Testing Pattern Overrides with a Keyboard and Screenreader
Enter
to edit one of the blocks, then pressEscape
twice to enter Navigation ModeEnter
to switch to Edit Mode — see that focus and context are lostEnter
on one of the editable fields, then tab away from the field — consider what the expected behavior should be in this scenarioediting-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
functions.php
: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.Enter
to use Edit ModeEscape
twice to use Navigation ModeEnter
on a bound block to enter Edit Mode, then start typingHere'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
The text was updated successfully, but these errors were encountered: