If you press backspace too many times in the url popover, it deletes the block, which I found unusual, and it feels like a bug, so I've removed that behavior. Input should be constrained in the popover. I think this is probably a hangover from a past implementation where the URLPopover used to automatically open.

The behavior was implemented in #50903.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: alexstine <alexstine@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: -3 B (0%)

Total Size: 1.74 MB

_{compressed-size-action}

Flaky tests detected in c6f1d5d.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/8921260980
📝 Reported issues:

• [Flaky Test] inserts patterns by dragging and dropping from the global inserter #48372 in /test/e2e/specs/editor/various/inserting-blocks.spec.js
• [Flaky Test] inserts synced patterns by dragging and dropping from the global inserter #61291 in /test/e2e/specs/editor/various/inserting-blocks.spec.js

The behavior was implemented in #50903.

Thanks for finding that, that's quite recent, so it surprises me.

I don't think there was any inconsistency though. If anything it creates more inconistency. Try the following:

1. Insert a buttons block
2. Open the link popover on a button
3. Press delete - note that the button block isn't removed

Same with other blocks that have link/url popovers.

Another inconsistency is that you can focus the button within the social link block (focusing the button inside the block is different to focusing the wrapper of the block), hit delete and nothing happens.

cc @richtabor @ntsekouras

I don't think there was any inconsistency though. If anything it creates more inconistency. Try the following:

1. Insert a buttons block
2. Open the link popover on a button
3. Press delete - note that the button block isn't removed

I think that's a bit different because in social icons we can only have links and therefore we have to open the link popover. I think it's more comparable to pressing backspace in an empty button, which deletes the button block.. I have no strong opinions on this one, but personally I feel it fine..

Another inconsistency is that you can focus the button within the social link block (focusing the button inside the block is different to focusing the wrapper of the block), hit delete and nothing happens.

I agree that this is not ideal, but I think we should fix this, instead of removing the other behavior.

I think that's a bit different because in social icons we can only have links and therefore we have to open the link popover. I think it's more comparable to pressing backspace in an empty button, which deletes the button block.. I have no strong opinions on this one, but personally I feel it fine..

I disagree, but that's ok. I think I'll remove it from this PR to unblock it and we can discuss it on an issue.

To go into more detail, I don't agree that it's the same as the button block, text content is different to a url. An input within a dialog is also very different to rich text content.

When the user inserts a button block, the caret is by default within the text content and in many blocks deleting all text content results in the removal of the block, so it's an expected behavior.

For URLs in both the button and social link block, the user has to carry out a specific action to open the link dialog, clicking on a button. At this point the user understands they're in a dialog, so they would expect it to behave just like any other dialog, with all their input constrained. In no other dialog does deleting all the text remove the block.

I agree with @talldan here. Backspacing inside a dialog should not remove a block. I'm not even sure how you make a case for good UX on something like that...

I've split out that change into another PR, so hopefully it fully unblocks this one - #61344.

A couple questions:

• To my understanding, the URLPopover component is planned to be replaced by the LinkControl, is that correct? Cc @richtabor
• By adding a role="dialog" and not hiding from assistive technology the content outside the URLPopover, this will basically become a non-modal dialog. While tabbing is constrained within the URLPopover, screen reader users can exit the URLPopover by using any of the several screen reader shortcuts to navigate content e.g. to jump to headings and I think with NVDA and JAWS they can also exit the URLPopover by simply arrowing. Are we OK with this @alexstine ? It wouldn't be a 100% compliant implementation.

@afercia It tests well for me.

<div class="components-popover block-editor-url-popover is-positioned is-alternate" data-wp-c16t="true" data-wp-component="Popover" role="dialog" aria-label="Edit social link" tabindex="-1" style="position: absolute; top: 0px; left: 0px; transform: translateX(294px) translateY(186px) translateZ(0px);">

Unless aria-modal="false" is set, it gets true by default so the content outside is indeed restricted.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-modal

Thanks.

Unless aria-modal="false" is set, it gets true by default so the content outside is indeed restricted.

@alexstine I'm not sure that's correct. Actually, the default value of aria-modal is false. Of course, when aria-modal is entirely omitted, there's no value and that should be treated as false by screen readers.

I'm guessing the fact a dialog content is restricted anyways by some screen readers when they find a role="dialog" with no explicit aria-modal="true" set may come from some internal implementation of the screen reader, which I would argue doesn't fully follow the specification.

By checking the Accessibility tab in the Chrome dev tools, it clearly shows the value of the modal property is false in this PR. Here's the values the browser exposes:

ARIA Attributes:

• role: dialog
• aria-label: Edit social link

Computer Properties

• Name: Edit social link
• Role: dialogf
• modal: false

Screenshot:

As such, I still think we should make a decision on whether to add an explicit aria-modal attribute or not.

• If we want this popover to be 'modal', then it should have an aria-modal="true' attribute.
• Otherwise, it can be omitted but it would be best to set an explicit aria-modal="false' IMHO.

One more question: should this semantics be added also to other popovers to insert links e.g. the LinkControl component?

@afercia Yeah, it's a fair point. It looks like NVDA anyway treats role="dialog" always as a modal dialog even if you set aria-modal="false". I just can't imagine screen readers pay this too much attention though because having to manually set aria-modal="true" is not something I've seen around the web often. I guess according to the MDN link, it is indeed false by default but I misread it. Screen reader support varies though, have a look.

https://a11ysupport.io/tech/aria/aria-modal_attribute#age-of-results

I say this gets merged, doesn't look like this would hurt anything. Just not sure it really does anything at this point.

Thanks.

Screen reader support varies though, have a look.

Yes, aria-modal isn't fully supported by VoiceOver and it was even more buggy when the Modal component was implemented a few years ago. At that time, aria-modal made the content itself of the modal dialog hidden from assistive technologies. See #6261 (comment)

That is the reason why the Modal component does not use aria-modal. Instead, it uses a small helper to hide all the rest of the page by the means of aria-hidden="true".

Regardless my question is still: Do we want this Popover to be 'modal'?
In that case, using only aria-modal="true" wouldn't be sufficient.
Otherwise, if we want this URLPopover to be a non-modal dialog, it can ship as is.

I still think that making the link editing experience is important so if role="dialog" is added to this popover, it should be added to all the other similar UIs to edit links e.g. the LinkControl and others, if any.