Update URL popover

[jameskoster]

It came up in #56203 that the edit URL popover could use some attention. Here's a mockup that attempts to tidy things up a little:

Changes

• The input label is visually hidden (having both "URL" and "Permalink" seems unnecessary). I think there's a reasonable argument to change this heading to "Slug" – keen to hear thoughts on that.
• Input uses new 40px sizing.
• View page link is now an icon button. I'm not entirely convinced this affordance is needed in this UI – there are more prominent links to the frontend nowadays (details panel, main View menu).
• Added a button to copy the URL.
• Added a / prefix to the input. The idea here is to make a visual connection to the full url without including it (as it could be very long).

[afercia]

A few accessibility notes:

The input label is visually hidden (having both "URL" and "Permalink" seems unnecessary).

Okay, but "URL" now is a sort of 'visual label' while the input field would be labelled "Permalink". While that would work for blind screen reader users, it wouldn't be OK for sighted users who use screen readers or speech recognition software users. The visual labeling must match the actual labeling.

View page link is now an icon button.

Icon-only buttons should be avoided and only used when there is not enough space e.g. in the toolbars. In this popover, there is sufficient space to use standard buttons with visible text.

Also, please let's avoid to visually place buttons within input fields.

Added a / prefix to the input. The idea here is to make a visual connection to the full url without including it (as it could be very long).

I think it is important to keep the full URL visible. While the input field contains only the slug, the full URL must be visible somewhere as it always has been across the history of WordPress. I think this has been already discussed at length since the first implementation of the permalink UI in the Editor.

[ohiawins]

Hola, folks!

Looking at this ticket with @acirujano and we had some thoughts:

• We feel that the current popover in the backend is functioning well with the Permalink field, explanation, and "Learn more." link below and the full URL being linked to the post or page.
• We are both designers and so we love icons but we think they would be better used outside the field perhaps, and we agree with Andrea that they could bring up accessibility issues if left inside.
• We have included a mock-up that includes inline icons.
• We do think the solution for tool-tips (external link and copy link) is an important addition.
• We think that the text should stay but it should be more consistent and spaced better.

We found the popover in the WordPress Design Library and started working on the spacing of the elements, Permalink and View Post/Page. We felt these sections were not separated well enough to give us a visual understanding that they do two different things but are both functions under the URL. So our proposed new layout is below. Also in the backend and in the Figma file capitalization is not consistent so we addressed this issue as well.

High FIVES!!
Ana and Ohia

[acirujano]

¡Hola!

This is the mockup that @ohiawins and I made.

It's included on the Proposals page in the WordPress Design Library in Figma.

Ohia and Ana

[acirujano]

Another thing we can consider is improving the titles. Permalink could be Slug, since what the user enters is the slug. And View Post or View Page could be Permalink, which would also be the same title for pages and posts.

Ohia and Ana

[afercia]

Another thing we can consider is improving the titles. Permalink could be Slug, since what the user enters is the slug. And View Post or View Page could be Permalink

Personally, I like the idea of calling things for what they are 👍
The term slug has always been used in the Classic editor and in the taxonomies admin pages. I'd only suggest to name it URL Slug. In the Classic editor, that's the label used for the edit permalink slug field, even though the label is visually hidden:

Also, in the Screen Options users can enable the Slug metabox, which appears below the post content area:

Thats a +1 from me to use the term 'Slug'.

Regarding the 'external' and 'copy' icons, I find a little confusing the former is only a visual indication while the latter is actually a button. Visually, they look similar but they serve different purposes. I'd rather have the Copy button look like a button with visible text. I'd also recommend to bring in some consistency with the 'post publish panel', where:

• The URL field is labelled 'Post address' (or 'Page address' etc.) while for consistency it should be labelled 'Permalink'.
• The Copy button is a button with visible text (which is better for usability and accessibility).

Screenshot:

[acirujano]

Thank you, Andrea, for providing the screenshots to ensure that the term "Slug" is appropriate.
The "external link" icon serves not only as a visual indicator but also functions as the external link itself. Nevertheless, I agree with you that the button with the text "Copy" is clearer and more suitable for accessibility. Therefore, I think this would be a better proposal. I have placed the copy button below and not in line because the permalink is displayed in full and can be quite long.

What do you think of this new proposal?

[ohiawins]

• I think if we are going to have such a big button it should say Copy Link.
• In the first solution proposed with our beloved icons we did not include a screenshot that includes the tooltips. @afercia do you think having those would help and then we omit the button for copy?

[acirujano]

I have proposed this button size for consistency (see attached screenshot).

I think it's a good idea to use a more descriptive text, as you suggested, @ohiawins. Perhaps it might be even better to use "Copy Permalink" to maintain the same terminology. I am attaching a new proposal that also takes into account the 2px corner radius on the button.

What do you think? What would work better? The icon with a tooltip or the large button?
And one more question: Is it necessary to include the option to copy the permalink?

[afercia]

• In the first solution proposed with our beloved icons we did not include a screenshot that includes the tooltips. @afercia do you think having those would help and then we omit the button for copy?

To clarify what's best for accessibility and, in my opinion, for general usability:

• Always prefer buttons with visible text.
• Icon buttons should only be used when there's not enough space to show visible text, for example in the block toolbar.
• In all the cases where there is enough space, use buttons with visible text as there's no reason to use icons.
• Ideally, all icon buttons should respect the 'Show button text labels` preference and show text instead of icon buttons when the preferences is enabled. Ideally, new design mockups should also provide the 'show text labels' version of the icon buttons.
• When it is necessary to use icon buttons because there is not enough space, icon buttons must always use a tooltip to visually expose the button accessible name. Worth noting the tooltip is a compromise for accessibility: the most accessible applications around show both icons and text.

I like the separated Copy button in the last screenshots. Maybe it doesn't need to be full width and I'm not sure it should be a primary button, but I like it ❤️

For reference, in #56854 I'm going to propose to change the post-publish panel to use the label 'Permalink' instead of 'Post address' for consistency. Screenshot:

[afercia]

Question for designers @WordPress/gutenberg-design

See screenshot below:

• Left: the current URL popover
• RIght: the current post-publish panel

These two UIs have a few common concepts but use different terminology etc. Besides these inconsistencies, my specific question is about displaying the 'full URL' (also known as 'permalink'): Why in the URL popover it's a textual link and instead in the post-publish panel it's a readonly input field? Is there any good reason to make them different? I'd think it would be better for consistency to use the same pattern. I think we can add a 'Copy' button for both cases, whether it's a textual link or an input field.

[joedolson]

From the accessibility bug scrub on 4/16/2024, we agreed that the design in @acirujano's Dec 8th comment has a lot of great characteristics: it's clear and consistent.

I agree with @afercia that I'm not sure the copy button needs to be full width or primary, but am fine with them as they are, regardless.

Improving consistency by labeling the link accurately throughout the UI would be good.

[afercia]

A few things have changed in the meantime and now the UI on trunk looks like in the screenshot below:

A few notes:

• First of all, the name of this setting changed from 'URL' to 'Link'. They are both incorrect. What users can edit here is actually the 'Slug' or 'URL Slug'. That's the terminology WordPress has been using for ages and there's no value in changing it. Such a change can only have one effect: confuse users.
• In the same way, the toggle button that opens the popover is labeled mentioning the term 'link' with aria-label="Change link: hello-world" which is clearly incorrect as 'hello-world' is not a link. Not to mention all the buttons in the Summary panel are labeled in a less than ideal way but I don't want to rehash the lengthy conversation from Improve "Visibility" and "Publish" labels in Post Settings #470 here.
• The input field uses an aria-details attribute. While technically correct, aria-details has poor support. Basically only NVDA and Orca have decent support. There is no great point with using a feature ignoring its actual support. I'd argue this input field doesn't need to reference the paragraph with the full link in the first place. A description such as http://mysite.org/hello-world/ (opens in a new tab) doesn't help and anyways users can still reach the paragraph by other means.
• The 'Copy' button is completely unlabeled. This is one more instance of an unlabeled control, which proves once again the base components are open to misuse Cc @ciampo
• In Update URL popover #56381 (comment) I asked to avoid to visually place buttons within input fields. I see that feedback has been completely dismissed and ignored.
• The 'Learn more' link points to an out of date documentation page that still shows the old UI.

[ciampo]

The 'Copy' button is completely unlabeled. This is one more instance of an unlabeled control, which proves once again the base components are open to misuse Cc @ciampo

@afercia instead of pinging me directly, could you add references to all places that you think need improving in a relevant issue that can be discussed with the whole @WordPress/gutenberg-components folks and the rest of the community? (for example, #51740)

[jameskoster]

That's the terminology WordPress has been using for ages and there's no value in changing it.

Despite being involved with the recent design updates I do tend to agree with this point. If 'slug' is too technical or confusing (as was suggested at the time) then it should be updated holistically.

I think we can potentially close this issue in favor of more specific ones to address these finer details. The copy button feels like something to address all at once, as Marco suggests.

[mirka]

avoid to visually place buttons within input fields

@afercia Could you elaborate on the reasoning for this? I find this to be an extremely common pattern (location bar in all three major browsers, clear button of a search field, reveal password button, etc.) and we're using it in multiple places in our component library as well. I failed to find anything about this on the web.

[afercia]

I think we can potentially close this issue

@jameskoster Sorry, I forgot this issue and in the meantime I created #61196 which overlaps with many points discussed here. Any objections to close this one and continue on the new one?

[afercia]

Could you elaborate on the reasoning for this

Anything that is non-native is inherently less accessible. The only native example of this pattern I can think of is the 'clear' button for the input of type=search. Anything else is not expected.

• First of all it's an icon button, with all the accessibility and usability problems of icon-only controls.
• Web form controls are natively separated objects. Each control has a specific purpose. An input is an input, a button is a button. They are separated, logically, functionally, and visually. Placing them together only for visual purposes violates the separation of concerns.

There's a golden rule for the highest level of accessibility: use native features. Don't reinvent form controls. This is simple, clear and accessible:

This is less accessible:

[mirka]

Could you elaborate on the reasoning for this

Anything that is non-native is inherently less accessible. The only native example of this pattern I can think of is the 'clear' button for the input of type=search. Anything else is not expected.

Thanks for elaborating. Personally I do not think those arguments are strong enough to conclude that this is clearly a bad inaccessible pattern that should be avoided. It is a well-established pattern that is used in a native search input, as well as in browser chrome. It sounds like more of a nuanced design issue that should be assessed in each context, since there are usability (or cognitive accessibility) benefits to decreasing the footprint of an unimportant, auxiliary button like "Copy".

[afercia]

since there are usability (or cognitive accessibility) benefits to decreasing the footprint of an unimportant, auxiliary button like "Copy"

Can you elaborate more on this please? It sounds like you are suggesting that icon buttons with no text are better for accessibility. Which is something I'd really argue about. Any data, research, or reference to support that statement from an accessibility perspective? Thanks,

[mirka]

It sounds like you are suggesting that icon buttons with no text are better for accessibility

I was only talking about the "button in text field" pattern. The button being an icon button is not an inherent property of the pattern — it could just as well be a text-labeled button. Simply moving a button into the associated text field decreases its footprint, and calls less attention to itself until the user moves their attention to the text field.

Though I do think that the use of icon buttons are also a nuanced design issue, rather than a clear case of "bad accessibility" in all instances. I agree that sometimes an icon button is clearly worse, but sometimes there's a tradeoff, and sometimes it could even be better than a text-labeled button.

[joedolson]

Generally speaking, the best way of providing labeling is a combination of a meaningful icon and text; Gutenberg seems to primarily use one or the other, and rarely combines them. One of the big advantages of combined buttons is that it helps create the association between an icon and text, so that if it's necessary for a button to appear without the text portion, that familiarity has been reinforced elsewhere.

The biggest question for me with icon-only buttons is essentially "how commonly is this icon used for this meaning?" Some icons are generally agreed on to have pretty universal meaning; e.g., the magnifying class for search. Others clearly don't have any universal meaning, e.g., the divided circle used to represent "Styles".

I think that the copy button icon is probably in a more ambiguous place between those two; it's somewhat common, but not really universal. Since we don't have a lot of user data for this, it's hard to make a definite call one way or the other.

I think we should absolutely have a more nuanced usage of icons in buttons; one that accounts for the distinction between universal icon patterns and unique icons, but I also think that's kind of a side issue here.

In the meanwhile, I'm going to close this issue per @afercia's comment above, in favor of #61196.

[afercia]

To me, icon-only buttons are acceptable only for a limited set of well recognizable icons.

About the recognizable meaning of icons I'd like to remind that not even the 'checkmark' icon has a really universal meaning as in some countries and cultures it does have a completely different meaning.

On top of that, a general principle for the highest level of accessibility should be that when the UI provides enough room for text, then the controls should use visible text. There's a lot of places in the editor UI where icons are used unnecessarily.

In limited cases they can be used but I'd like to mention that all the most accessible applications and software I've seen across the years use both icons and visible text, when possible. There's plenty of examples of this ivon + text pattern, including some mobile devices UI e.g. Android.

Specifically to the Copy button icon: yes it's in an ambiguous place. I wouldn't call it as an icon with universal meaning. However, and more importantly, I do think it's very important to consider also the usage of a specific icon in relationship with other icons. An example: these are 3 icons in use in the editor:

Honestly: which is which? Yes, the context helps but how much processing is necessary to distinguish these 3 icons? How much cognitive load for users?

The biggest question for me with icon-only buttons is essentially "how commonly is this icon used for this meaning?"

I'd like to remind that it's not just about that. Icon-only controls are inherently not accessible for speech recognition software usrs, for example. Unless they visually expose the accessible name. Yes, speech recognition software wo have workarounds but still it's a terrible experience for them. Not to mention users with cognitive impairments.

Lastly, there are states of the editor UI where the usage of icons with no text makes the UI hardly undertandable. One example: imagine you are a first-time user of the editor and you have to decipher these UIs:

Without text, I only see dashes, dots, small arrows and numbers and I don't have idea what these buttons are about.