Use inert attribute instead of useDisabled #44865
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| <?php | ||
| /** | ||
| * Updates the script-loader.php file | ||
| * | ||
| * @package gutenberg | ||
| */ | ||
|
|
||
| /** | ||
| * Registers vendor JavaScript files to be used as dependencies of the editor | ||
| * and plugins. | ||
| * | ||
| * This function is called from a script during the plugin build process, so it | ||
| * should not call any WordPress PHP functions. | ||
| * | ||
| * @since 13.0 | ||
| * | ||
| * @param WP_Scripts $scripts WP_Scripts instance. | ||
| */ | ||
| function gutenberg_register_vendor_scripts_62( $scripts ) { | ||
| $extension = SCRIPT_DEBUG ? '.js' : '.min.js'; | ||
|
|
||
| $script = $scripts->query( 'wp-inert-polyfill', 'registered' ); | ||
| if ( ! $script ) { | ||
| $scripts->add( 'wp-inert-polyfill', gutenberg_url( 'build/vendors/inert-polyfill' . $extension ), array() ); | ||
| } | ||
|
|
||
| $script = $scripts->query( 'wp-polyfill', 'registered' ); | ||
| $script->deps = array_merge( $script->deps, array( 'wp-inert-polyfill' ) ); | ||
| } | ||
| add_action( 'wp_default_scripts', 'gutenberg_register_vendor_scripts_62' ); |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,7 +5,6 @@ import { store as blockEditorStore } from '@wordpress/block-editor'; | |
| import { __, sprintf } from '@wordpress/i18n'; | ||
| import { useSelect } from '@wordpress/data'; | ||
| import { useEntityProp } from '@wordpress/core-data'; | ||
|
|
||
| /** | ||
| * Internal dependencies | ||
|
|
@@ -22,13 +21,8 @@ export default function PostCommentsPlaceholder( { postType, postId } ) { | |
| .__experimentalDiscussionSettings | ||
| ); | ||
|
|
||
| return ( | ||
| <div className="wp-block-comments__legacy-placeholder" inert="true"> | ||
|
There was a problem hiding this comment. Why exactly are we disabling this? There was a problem hiding this comment. This is just mirrors what existed before the PR. Basically we had a useDisabled hook that poly fills what "inert" does. So I'm not sure we changed anything in behavior here. I believe these "inert" within components are there because these blocks are "interactive", people can interact with them in the frontend but they are not meant to be interacted with in the backend (or navigated within). I'm not entirely sure that we really want to keep this visible for screen reader users, they are just mean to offer a visual representation of what the block will look like in the frontend but for interactions purposes, the intent is to hide these entirely. If we really want to leave a "trace", we may add a label maybe or something like that? There was a problem hiding this comment. @youknowriad That's the problem. We are giving sighted people information keyboard/screen reader users don't have access to. If the content on the back-end is really not important, let's add Thanks. There was a problem hiding this comment. I think I see what you're coming from but the reality is that the editor is also meant to be WYSIWYG and that concept doesn't really translate into screen readers. Sighted users will see something different visually between the backend and frontend and consider this a visual bug. In terms of interactions, I agree, both sighted and screen reader users should have the exact same thing but the visuals are important for sighted users. Would it help if we add a label or something saying "Visual Preview of block/whatever we're previewing" or something like that? Also, this is independent of the use of inert, it has always been this way in the editor. There was a problem hiding this comment.
That's got to change but I guess it can go into an issue for further discussion. Labels don't help here because the preview itself is still not communicated equally. Why is it not possible to disable interactions with blocks in an accessible way? #54322 accomplishes just that. People with vision can't interact with the block and screen readers can still see the block content but cannot interact with the block. We've got to quit caring so much about this front-end vs. back-end. Honestly, do you think anyone at all would notice the usage of There was a problem hiding this comment. Below example shows how this can still remain accessible but preventing the form from actually working. <html>
<head>
<title>Test</title>
</head>
<body>
<h1>With inert</h1>
<form class="form1" action="https://www.google.com" method="GET" inert>
<input type="search" value="" name="search1" aria-label="Search 1" placeholder="Search 1" />
<input type="submit" value="Search 1" />
</form>
<br />
<h1>Accessible way but more work</h1>
<form class="form2" action="https://www.google.com" method="GET">
<input type="search" value="" name="search2" aria-label="Search 2" placeholder="Search 2" aria-disabled="true" />
<input type="submit" value="Search 2" aria-disabled="true" />
</form>
<script type="text/javascript">
const form2 = document.querySelector('.form2');
form2.addEventListener('submit', function(e) {
e.preventDefault();
} );
</script>
</body>
</html>There was a problem hiding this comment. I've created an issue where can record discussions and debate alternatives: There was a problem hiding this comment. Now that I think about it, all of our usage of "inert" can be seen as "screenshots". In that sense, I think maybe the solution going forward is to use a role="img" on these elements with a label. When you show a preview of a block or a template, it's just like an image. |
||
| <h3> | ||
| { | ||
| /* translators: %s: Post title. */ | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing that the preview is disabled seemed like a meaningful test — instead of deleting it, we could have replaced it with user actions? (ie. user tries to interact with block preview, nothing happens)