Try to make link UI in the button block consistent with other link interfaces

[talldan]

See also #2216, #6392

Description
#10128 involved quite a bit of iteration on the link UI in the button block, which was perhaps out of scope for the related issue. Eventually, a simplified design was settled on in order to move the PR forwards, but there's was acknowledgement that we're still left with inconsistencies across link user interfaces in Gutenberg.

This issue summarises some of the explorations on that PR and captures that further exploration may be required.

Attempted in #10128:

Using the link popover in the button block (#10128)

For:

• Brings consistency across link interfaces

Against:

• This approach was very hard to make accessible. Since the link input field is in a popover it wasn't possible to tab from the button text to the link input and back again.

Using a button to open the link popover (#10128 (comment))

For:

• Is still consistent with other link interfaces
• Solves some accessibility problems inherent other solutions

Against:

• It's a bit weird, a confusing extra step that users have to take

Other info:

• It was suggested that the button could be a toolbar button, though I think this hides an essential piece of functionality for the button block.

An inline version of the link popover (#10128 (comment))

For:

• Is still consistent with other link interfaces
• Solves some accessibility problems inherent other solutions

Against:

• It's visually busy

Other info:

• I discovered afterwards that this is similar to how coblocks displays the link user interface in its blocks. For example: Add optional links to individual gallery images godaddy-wordpress/coblocks#580
• Some further design feedback here on this option: [Enhancement] Introduce Link Target in Button Block #10128 (comment)

A simplified version of the link UI (screen capture is similar to what was implemented)

For:

• Visually clean
• Solves some accessibility problems inherent other solutions

Against:

• Still inconsistent with other link user interfaces.

[afercia]

Seems to me one of the inconsistencies (and an actual problem for accessibility) is that when a link suggestion is highlighted, tabbing away from the input field sets the link.

This is a problem because the Tab key must be reserved for keyboard navigation. Triggering an action (setting the link) while users just want to navigate away would be completely unexpected.

[talldan]

Yep, though just to clarify, the link is updated on every keypress not when the input blurs. That's not something new, but the way the button block worked before #10128 as well.

Introducing a submit/apply button would make it more consistent and probably help in the implementation of #16494 as well. Could even be done as part of fixing that issue.

[talldan]

Closing as the link UI has recently been updated.