Gutenberg's use of "inert"

Gutenberg uses the inert HTML attribute to disable blocks in the editor.

For instance, in the useDisabled hook and on template parts when editing a page in the Site Editor (via useBlockProps).

The assumption is that Gutenberg should have a good reason to disable blocks.

The use of "inert" on disabled blocks impacts accessibility by hiding them from the accessibility tree. In cases where disabled content conveys information in some way, or has, albeit, limited interaction, screen readers/keyboard users have no knowledge of its purpose or existence.

The argument for using "inert" in the editor is that disabled blocks are, as far as the browser and user are concerned, functionally "hidden". They are unfocusable and non-interactive and therefore serve no purpose other than placeholders.
Could the editor communicate this intention in another way while retaining "inert"? For example a label that describes the disabled state and what is being disabled?

Related discussions:

• Use inert attribute instead of useDisabled #44865 (review)
• Add inert attribute to disabled blocks that have only disabled descendants #51079 (review)
• https://wordpress.slack.com/archives/C02QB2JS7/p1694227397534749

Alternatives

I'm not proposing any specific approach, just trying to collate and summarize various discussions.

A proposed approach would be to create a general callback to prevent default behaviour via event handlers, potentially via event delegation/capturing on the editor container. For example, click, focus, keyDown, change etc.

To disable interaction for all core blocks while maintaining keyboard navigation would be challenging. Each core block is unique. Take for example the search block, which contains several focusable elements including a input field and a rich text component.

More time consuming, each block could handle its own disabled state separately. So, the idea is that a block would receive a prop to inform it that it has been "disabled" in the editor and it would render itself accordingly. Perhaps something similar to how the ally library disables elements.

Here's an example of a PR that attempts to accomplish this for the table block:

• Table of contents block accessibility improvements #54322

Questions

• Are there any short term alternatives, such as labels that describe the disable areas?
• For sighted users, should there furthermore be a visual indication that a block is disabled?

Related reading

• https://github.com/WICG/inert/blob/main/explainer.md#the-case-for-inert-as-a-primitive
• https://robdodson.me/posts/building-better-accessibility-primitives/#problem2disablingtabindex