Add inert attribute to disabled blocks that have only disabled descendants #51079
Conversation
noisysocks
added
[Type] Bug
|
Size Change: -858 B (0%) Total Size: 1.39 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 0380be5. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5129400285
|
There was a problem hiding this comment.
This is working as advertised for pages.
With the patch enabled:
- When selected a page from the site editor bar (and editing it), only the title/post-content/featured-media are editable, and I cannot edit the site title in any browser
I checked without patch while editing a template and things are functional but a little inconsistent:
- the inert attribute appears on header group block wrapper, navigation, feature image only until edited
I'm assuming that this will be more consistent as each block has a blockEditingMode?
Checked in Chrome, FF and Safari
noisysocks
deleted the
update/add-inert-to-disabled-blocks-with-disabled-descendants
branch
…dants (WordPress#51079) * Add inert attribute to disabled blocks that have only disabled descendants * Fix typo --------- Co-authored-by: ramon <ramonjd@gmail.com>
noisysocks
added
the
[Feature] Page Content Focus
…dants (WordPress#51079) * Add inert attribute to disabled blocks that have only disabled descendants * Fix typo --------- Co-authored-by: ramon <ramonjd@gmail.com>
There was a problem hiding this comment.
@noisysocks Exactly how is this supposed to work for keyboard-only users when they attempt to focus a block with inert? For someone like me who has no vision, I am going to sit here and wonder why my navigational keys are not working. Adding this to the block wrapper is not a good solution. We need to use another attribute to communicate to users that the block is disabled because currently, focus is simply restricted and so is any screen reader virtual mode due to the implicit aria-hidden effect.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inert
I made a more general announcement in core-editor, this is really a pattern that we're using very wrong at the moment.
https://wordpress.slack.com/archives/C02QB2JS7/p1694227397534749
This is good for content outside dialogs but this attribute takes the power away from blind users to know what is happening in the UI.
|
Thank a lot for the feedback @alexstine 🙇🏻 @noisysocks is away for a while, but I can try to provide some context.
When editing a page in the site editor, the editor renders a page's surrounding template. The blocks that comprise the surrounding template have the inert attribute. As far as I'm aware, inert blocks in this context should be, as far as the browser and user are concerned, completely non-interactive. That is: unclickable, unfocusable and un-everything. The only information they convey is ornamental: to display the surrounding visual context of a page while editing that page's context. Page editing in the site editor should work as if the surrounding template's elements are not there in my opinion. Before work on #49404 started, they weren't rendered at all.
Is keyboard navigation completely broken for page editing in the site editor? I'm 100% not an expert, but I can manage to tab around and edit the page.
What do you think? What would be the best way to communicate to users that the areas are in fact, for the purposes of editor functionality, "dead zones" or effectively hidden? I did try a few things without the inert, mostly attempting to disable clicks, focus and keyboard events via javascript for blocks. It worked, but it was hard to get right. The search block for example, including other blocks with child inputs or rich text blocks, is always editable via the keyboard - we want to disable typing but not tabbing keyboard events. I didn't try the "change" event for inputs, so there's probably more space to explore. So I think something more lower level might be required, that is, a flag in the block context that tells a block whether it should be disabling itself completely. @youknowriad had a related comment a while back about this. I'm not sure how we could execute this without tinkering with each core block since all core blocks are different. |
This is what makes accessibility in Gutenberg so difficult but here we are. Each block has to be dealt with under different sets of conditions. The problem is, you are stating that these blocks are here for visual context but for non-sighted users, there is now no way for them to have the same context. This spells accessibility problem from the start. Not sure what the solution is but this isn't it. I guess we'll have to go through and edit every block to ensure blocks stay accessible if back-end should not be used. Thanks. |
I hear you. I was coming from the perspective that they offer no much more than disabled areas, and was framing it akin to inert content beneath a modal. Is there a way to mitigate things in the short term for this specific issue through description or other labelling?
It sounds as if we need wider input here on a technical approach. I can create an issue and try to summarize as best I can, but I'd appreciate it if you could fact check me on this. Thanks again for your input. |
|
@ramonjd I just shared a code sample over on this PR. Maybe this helps explain how it is possible to think about accessibility while still disabling the block? |
Thanks for sharing! That was in the direction of what I was experimenting yesterday, however using event delegation on the editor canvas to catch bubbling events. It kinda works in its own hacky way, but I noted that preventing keyboard interaction required some exceptions, e.g., Tab and arrow keys for example. I'll note this on the issue that I create today. Cheers! 🍺 |
|
Here's the issue: |
What?
Follows #50643.
Currently if a block has an editing mode of
'disabled'then it receives CSS that putspointer-events: noneon it.In this PR we go further and set the
inertHTML attribute so long as all of the block's descendants are also disabled.This lets us apply inert to as many elements as possible while still preserving the ability to interact with non-disabled descendants of a disabled block.
Why?
The
inertattribute has fewer bugs to do with triggering e.g. selection events, is better for assistive technologies, and is faster.How?
useBlockProps()has been updated to addinertif possible.BlockListBlockstill adds the.is-editing-disabledclass (which haspointer-events: none) as it did before. The two coexist.We don't check
contentOnlytemplate locking here because it's very unlikely that a block withtemplateLock = 'contentOnly'has no editable inner blocks. The point of using'contentOnly'locking is to have editable content within the pattern.Testing Instructions
pbpaste | git apply.If the patch is annoying you could also merge this branch into #50857 to test.