A11y review of Link Control/UI design refresh

[getdave]

With a new UX/Design for the Link interface being proposed in #50891, let's:

• do a review of the proposed design and highlight any issues that could be resolved now prior to implementation.
• make recommendations for implementors on the relevant Issues linked from (LinkControl Refresh #50891)
• make recommendations in new Issues and add them to LinkControl Refresh #50891.

Part of #50891.

[getdave]

@jeryj Could we draw on your expertise here? Once we've done a first pass I think it would be a great idea if you could take this to the Core a11y team chat and ask them for input on specific questions.

Everyone is of course more than welcome to participate upfront, but I"m conscious that the team are across many efforts and so anything we can do to streamline the effort required by them will help.

Thank you 🙇

[jeryj]

Thanks for flagging this early, @getdave! And thanks for all your efforts on improving the Link UI, @richtabor! I have some recommendations, but nothing that I think will be major. Most of the things, I hope, will make things more accessible and simpler for everyone 🤞🏻

No Results Found

I think having a message that says, "no results found," or simiilar would be helpful here. Otherwise it's unclear if the search failed, is still loading, etc.

Cancelling after Page Selection

Love the labelled inputs here! In this state, does the cancel remove the link entirely (cancelling the whole link insertion) or does cancelling only remove changes you've made to the link and text inputs? If it's the latter, maybe the cancel button should also be disabled so it's clearer that it doesn't remove the link? Also, does clicking the link close the dialog along with it? I'm not sure how this interaction should work. I'll ask those more knowledgeable :)

Same input labelling and order in Post Link Inspector Panel

The post link block inspector lists the inputs in a different order with different labels. For consistency, I think the inputs in the Link UI and the Block Inspector should be labelled the same and have the same order.

Hide or Remove Open in a New Tab

I know that opening links in a new tab is a common pattern used on websites, but opening links in a new tab is almost
always considered an accessibility issue. Very rarely does it aid accessibility, and it's in pretty specialized situations. I'd say let's remove it entirely from the Link UI, or at least hide it as it was in the previous version of the Link UI, as revealing so readily will almost certainly further proliferate a common inaccessible pattern.

Flow when Editing Link Text

I think this interaction will be hard to communicate to all users for a few reasons:

1. Typing in a field is changing the state of the Link UI which removes the other fields. Where did they go? When do they reappear?
2. Selecting a value for the link, also changes the title of the link. This could be unexpected, as maybe they had already set their title to the value they wanted, such as a Pizza chain with a page with the title ,"Our Locations" and in the Nav they only want it to say "Locations." It's not clear that by changing the link value I'm also changing the title value.

This feature is essentially starting over on the page selection without deleting the link and trying again. In the current Link UI, clicking the "unlink" icon at the top right has this behavior already. I think that a separate button that allows you to arrive at this "starting over," state is enough and more preferable than combining the URL input to have impact beyond editing the URL. Also, it's a win for simplicity and shipping sooner since that button is already in the UI 😉

Always have Add Link Button if the Search is URL-formatted

In the flow, the Add Link button is only present when there are no search results. I think anytime the text in the search field is formatted like a URL that the Add Link option should be visible. Also, I think it should be within the results and not in the section afterwards, as it is a dynamic value returned as a result of what they type in the search field. It will likely help with accessibility to have the value returned within the list of search results since its value is connected to that field.

Link settings button should be adjacent to the fields it reveals

The button to open the additional link settings should be adjacent visually and HTML-wise to the fields that it reveals. So, if the additional fields open at the bottom of the Link UI pane, the Link Settings button should also be at the bottom of the pane. This greatly aids in managing focus and having an expected focus order. For example, if the button to reveal the settings is at the top and the additional fields are at the bottom, it will take several tab presses to reach the settings it opened and several back to close it again. Also, by having them next to each other, it's clearer what the relationship is between the button and its settings based on proximity.

Labelling Search Input for Specific Cases

I was going back and forth on recommending a visible label for the search ui input. The reason I didn't press it was that really anything you search in the default version will return something and it could be formatted like a URL or plain text, etc. So there's not a specific instruction to really recommend.

However, in these cases, it looks like the search is restricted to a specific case, such as Tags, Category, or Post titles. When the search input is restricted to a specific case, we should have a visible label that indicates as such. Having it in the placeholder isn't enough, as it will disappear as soon as the input is focused (which is likely programmatically done immediately when the link ui is opened, meaning it's unlikely anyone will even see the placeholder text).

[getdave]

Thank you so much @jeryj 🙇‍♂️

cc @richtabor on the above.

[alexstine]

There a PR yet?

[richtabor]

Good stuff!

I think having a message that says, "no results found," or simiilar would be helpful here. Otherwise it's unclear if the search failed, is still loading, etc.

There would still be "Add block" or "Add new page/link: {query}" as the primary suggestions/results. I do want to keep the current heading as visually hidden (#50977) but I suppose we could also add a condition for if there are no results as well.

Love the labelled inputs here! In this state, does the cancel remove the link entirely (cancelling the whole link insertion) or does cancelling only remove changes you've made to the link and text inputs?

Discards current changes and closes the popover; does not remove the link.

The post link block inspector lists the inputs in a different order with different labels. For consistency, I think the inputs in the Link UI and the Block Inspector should be labelled the same and have the same order.

Yes, 100%.

Selecting a value for the link, also changes the title of the link.

I'd argue that the expectation of picking a new suggestion would populate all properties of the suggestion (link and text). But I do recognize that we do not have this logic in place today.

Also, I think it should be within the results and not in the section afterwards, as it is a dynamic value returned as a result of what they type in the search field.

I lean towards having it in a footer area so that it doesn't present like a result. It should be clear that there is not an existing result.

So, if the additional fields open at the bottom of the Link UI pane, the Link Settings button should also be at the bottom of the pane. This greatly aids in managing focus and having an expected focus order. For example, if the button to reveal the settings is at the top and the additional fields are at the bottom, it will take several tab presses to reach the settings it opened and several back to close it again. Also, by having them next to each other, it's clearer what the relationship is between the button and its settings based on proximity.

Yes, I share this concern. It could be fine to have "Add new tab" placed after "Link". But that does introduce another oddity if we add additional controls for say Link Rel and Class. The Settings icon would open the drawer of all those additional controls.

However, in these cases, it looks like the search is restricted to a specific case, such as Tags, Category, or Post titles. When the search input is restricted to a specific case, we should have a visible label that indicates as such.

Search is not restricted to specific cases except for these block variations. I think the type indicated on each result is indicative of the items that are suggested (for both cases).

I think that a separate button that allows you to arrive at this "starting over," state is enough and more preferable than combining the URL input to have impact beyond editing the URL.

The URL input works like this today; where if you start typing, you get results suggested for you.

[jeryj]

@alexstine - No, this is just the design of what we would implement. Trying to do it right and get an accessibility review from the mockups first to catch anything that would clearly be an accessibility issue.

[alexstine]

Once there is a PR, I can help. For now, you need someone with sight. CC @afercia @joedolson .

[joedolson]

Selecting a value for the link, also changes the title of the link.

I would never expect changing a link target to change the title of the link, and I think that could become quite irritating. From a writing flow perspective, my process is generally to write, then add links after having written. So I've already written my link text, which will usually be within a sentence structure. If selecting a link target imposed the title of that item on my text, I'd almost always need to then edit the text back to before. I have trouble imagining a scenario where I would expect changing a link to also change the written text.

I agree with @jeryj that the positioning of the settings button needs to be in proximity to the controls it opens.

As regards removing the 'open in new tab' option, I think that's a very difficult problem. It is a legitimate choice, and does have relevant applications, so not providing a mechanism to do that can create other, more severe accessibility problems (loss of data without warning.) Opening links in new tabs is not, technically, the accessibility problem; it's doing so without providing warning to the user. Ideally, WordPress would take control of appending an accessible notification that a link opens in a new tab so that users were informed of this, rather than simply removing the option.

[richtabor]

I would never expect changing a link target to change the title of the link

I think there’s some confusion. This proposal is suggesting that when you search and pick a result, it is added to the link.

Perhaps another area of confusion is how Navigation Links and inline links could act differently. If I search for and add a link to my navigation, I surely want to whole entity applied.

[joedolson]

I think there’s some confusion. This proposal is suggesting that when you search and pick a result, it is added to the link.

I'm not clear what that means. Do you mean only if you are searching without text already selected? I could see a logic that it adds the text at any time that the context doesn't already have text. E.g., when editing posts, you select text then add a link; in that case, it does not change anything; when adding a link to a navigation menu, there is no existing text node, so it inserts the text as default.

[afercia]

Thank you for the in-depth exploration. I'd agree with most of what @jeryj and @joedolson said.

Can we please try to describe the three flows in plain text rather than by using the mockups from the issue at #50891 ? I'd love this to be accessible for everyone. Please do feel free to edit the description below to integrate or correct where necessary.

Inline link

• search or type > select and submit > link is inserted > popup closes
• enter new link or new page > submit > link is inserted > popup closes
• the edit UI is shown again only when selecting the link in the post content

Navigation link

• search or type > select and submit > link is inserted > popup stays open > UI transforms into the Edit link > link field is still searchable > searching or type tranforms the UI back into the search / selection UI > current inserted link details are displayed at the top together with the Unlink button
• enter new link or new page > submit > link is inserted > popup stays open > UI transforms into the Edit link > link field is still searchable > searching or type tranforms the UI back into the new link or new page UI > current inserted link details are displayed at the top together with the Unlink button
• Add block > submit > UI transforms into the 'Quick inserter' > a 'Back' button allows to transform the UI back into the search / selection UI

Image link

• search or type > select and submit > link is inserted > popup closes
• the edit UI is shown again only when clicking the 'Edit link' button in the block toolbar
• Note: the mockup uses the 'Unlink' icon. I think this should be the 'Edit link' icon instead.
• Link to image file / Link to attachment page / Add new page: the mockup doesn't clarifies what the flow is: does the popup closes or stays open to show the edit details UI?

[afercia]

Based on the above, my main concern is the popup content that 'automatically' transforms into something entirely different. To my understanding, in at least two flows the entire popup content is replaced and shows the Edit UI or the Quick inserter. I'd say this is an unexpected change of context and it's inherently problematic for accessibility. I'd tend to think it adds cognitive load also for sighted users. I'd definitely prefer different UIs to be shown separately. The dynamic change of content should be avoided.

Also, I'm not sure I fully understand why the popup closes for the inline and image links and instead it stays open for the navigation links. I do realize the flow is slightly different but I'm pretty sure users would be confused with this different behavior. If we assume that it is important to show the Edit UI after selection / insertion of a link, then I'd say this behavior should be consistent and happen for all flows.

One more concern for keyboard accessibility:
When the popup stays open and I don't make any change: how do I close it and submit by using the keyboard?
Seems to me at that point I can only either click the Cancel button or press the Escape key. That would be completely counterintuitive as both Cancel and Escape should be reserved to cancel the current action.
There's no 'Apply' or 'Save' button because the link is already inserted. Edit: To clarify: the 'Save' button is disabled.

Lastly, I'd consider to move the 'Unlink' button at the bottom and use a button with visible text. A secondary red button could work. Actually, when editing, there are three available actions: Cancel, Unlink, and Save. I'm not sure why the Unlink action should be buried down into an Icon button (which comes with its own a11y problems) and be displayed separately from the other actions.

[afercia]

Feature request: glad to move this to a separate issue, if desired.

Image link

When linking an image, the image alt text determines the accessible name of the link (the link 'text'). It would be great to make the Link UI provide the ability to edit the image alt text. This would also be a good opportunity to educate users and inform them they need to provide a meaningful alt text that described the link purpose.

To clarify, the following markup would not be appropriate, because the alt text describes the image. The link purpose / destination is unclear:

<a href="https://unicornsland.org">
    <img src="..." alt="A white unicorn">
</a>

A more meaningful and accessible markup would describe the link purpose / destination in the image alt text:

<a href="https://unicornsland.org">
    <img src="..." alt="Go to the Unicorns land">
</a>

The image alt text should be editable both when inserting an image link for the first time and when editing an existing image link. A short description below the alt text input field may help users understand that in this context the image alt text is, actually, the link 'text'.

[richtabor]

This is a much more confusing experience. Note that we also have unlinking in the toolbar control where this UI is invoked. Perhaps we don't need an additional unlink item in the LinkControl itself:

[richtabor]

in at least two flows the entire popup content is replaced and shows the Edit UI or the Quick inserter. I'd say this is an unexpected change of context and it's inherently problematic for accessibility.

Currently, we have a "preview" state of the control, before you can access link editing. And when you select "Edit", the component invokes an edit state (changing all of the UI).

What I'm suggesting is that instead of having to select on a link, then select edit (have the UI change), then make edits — the edit controls are already rendered, as soon as a link is selected.

Are you suggesting the existing flow is more suitable?

[richtabor]

When the popup stays open and I don't make any change: how do I close it and submit by using the keyboard?

You can either use the "Cancel" button (same as today) or press ESC (also works today).

[richtabor]

It would be great to make the Link UI provide the ability to edit the image alt text.

That's interesting. It would be nice to auto-set the Image block's alt text if "Link to attachment page", or Link to image file" options were selected. Would be a nice follow-up to explore.

[richtabor]

I appreciate all the input team — good stuff. Here's an iteration based on the above:

Notable changes:

• Place "Text" field first, then "Link" field.
• Change settings icon to a toggle titled "Advanced" below the "Link" field.
• When toggled, the advanced link settings are available below the toggle.
• Selecting an entity does not imply text change

[getdave]

I much prefer the link settings in the position they are shown in this mockup (i.e. below the fields). This is what they currently do on trunk and have done for a while now in the Gutenberg Plugin.

[jeryj]

What I'm suggesting is that instead of having to select on a link, then select edit (have the UI change), then make edits — the edit controls are already rendered, as soon as a link is selected.

I like the flow you're recommending - bring up the edit controls from the beginning.

[jeryj]

Notable changes:

Place "Text" field first, then "Link" field.
Change settings icon to a toggle titled "Advanced" below the "Link" field.
When toggled, the advanced link settings are available below the toggle.
Selecting an entity does not imply text change

These are all great to me! Thanks so much for taking the time to solicit feedback, listen, and thoughtfully implement it ❤

[scruffian]

Since the review is complete I'm going to close this.

[getdave]

I believe @richtabor has updated the designs in the main Issue to reflect the results here.