<LinkControl> a11y review

[getdave]

With the new <LinkControl> component being the new default hyperlink creation UI in the Editor it's important it is as accessible as it possibly can be.

PR authors should reference the Core a11y handbook for guidance on a11y when addressing these issues.

Some areas to focus on:

• Is the "selected" link UI state perceivable to non-sighted users.?
• When switching between "edit" and "selected" UI state do we need to communicate the change in state via aria-live (we would use @wordpress/a11y speak() for this)?
• Keyboard a11y - should be possible to manipulate the entire control without a mouse.
• When the control is opened do we need to actively announce the current state of the link to screenreaders if it's in "selected" mode.
• Is the text <input /> element labelled appropriately? Are placeholders suitable? Any other missing a11y attributes?
• Are the individual search result "suggestions" marked-up in the most appropriate way? Are there any enhancements to make these more accessible?

Known Issues requiring fix

We should create new Issues for each problem encountered so they can be addressed piecemeal rather than as an epic PR which risks being blocked.

• ?

[jeryj]

#19850 is attempting to fix the focus loss that happens when clicking the X reset button on the search input.

[jeryj]

I started on a keyboard audit of the LinkControl. I'm far from an accessibility expert, but I am trying to learn more, so please keep this in mind when reading and responding to my thoughts here 😅

Suggestions disappear when tabbing from url input to submit button

Steps to Reproduce

• Open link control with suggestions (such as when adding a new navigation link)
• Press down to highlight a suggestion
• Tab to Submit button
• Suggestions disappear

Notes
It seems like pressing tab inserts the selected url into the link control input. I'd think it should keep the suggestions open and not count the tab as a select of some kind. On forms, a tab would select the value you had (such as on a select/dropdown), so I do kind of get the interaction. It feels off though since there is a submit button.

Large focus jump on arrow press when focus is inside LinkControl

Steps to Reproduce

• Add a new link somewhere to open LinkControl
• Press up or down arrow
• Focus moves to bottom or top of document (depending on if you pressed up or down arrow)

Notes
When tabbing from adding a new Navigation Block link, focus is trapped until you press escape. I'm not sure if this is what we want or not. Is it a modal? If so, then up/down arrows shouldn't navigate off the LinkControl. If we want to allow for up/down keypresses to move off of the LinkControl, then it should likely just get moved back to the previously focused text or whatever would have been focused from pressing up/down had the link text been focused.

Disconnected Keyboard UX to get into link control to edit existing link

Steps to Reproduce

• Add a link to a paragraph
• Click somewhere in the paragraph that is not the link
• Move the text caret to the link
• LinkControl will open, with focus staying on the link text
• To move focus into the LinkControl, you have to press cmd+k, even though the link control is visually open already.

Notes
I'm not sure the best solution here, just that I expected to be able to move into the LinkControl with a keypress (not cmd + k) since it was visible. Also, there doesn't seem to be any way to close the LinkControl while the caret is on the link text. For consistency sake, I think it may be best to not automatically open the LinkControl when the cursor is on the link text.

Differences between Navigation Block LinkControl and Inline Link LinkControl keyboard interactions

• When using the Navigation Block, focus is trapped in the LinkControl until you press esc, up or down.
• When using the inline links (as in a paragraph), focus is not trapped in the LinkControl. You can tab off of it and focus will move to the top of the page. esc does nothing, but the up and down arrows behave the same (moving focus to first or last block on the page).

Notes
LinkControl seems to be having an identity crisis. I think it needs to decide if it's supposed to operate like a modal or not. The interaction of being able to tab off of the LinkControl and have focus return to the top of the page is definitely an added issue here. I don't know if it should be allowed to be tabbed off of with focus returning to the text, or operate like a modal where it needs to be closed via esc. I think up or down closing it is fine if focus is moved back to the link text, but, as noted, I'm far from an accessibility expert 😃

[enriquesanchez]

Disconnected Keyboard UX to get into link control to edit existing link

I also found this disorienting. I did not know I could get there with cmd + k as @jeryj points out.

@MarcoZehe would you mind helping us here? Have you had any success accessing the controls to edit an inline link in a paragraph text? That is, after an inline link has been created, go back and edit it.

[MarcoZehe]

First of all, it is good UX that the cursor stays in the link text even though the link UI opens. There is nothing more frustrating than the cursor jumping away from the text you're trying to review when some other UI part gets displayed. The same is true for autocompletes, btw. Like the Twitter web UI grabbing focus when you move cursor into a mentioned user name or hash tag. Visually, you may be able to "indicate" (read: fake) focus being in two places at the same time, but for keyboard users, especially screen reader users, there is only one point of focus at any given moment, not two or more, just one. DOM focus for the browser can also only be in one place at a time, too.
2. having said all that, using the same keystroke to edit an existing link when the cursor is on it is common keyboard UX. You can look in Gmail, Google Docs, Thunderbird, Apple Mail, or what have you, to find the same pattern. As soon as the cursor is inside a linked text, CMD+K will bring up the UI to edit the link, not add a new one. In a classical menu system, the label for the menu item might even change to "Edit link" instead of "Insert link". Removing a link always has a different keystroke.
3. And a word about modality: This thing should be modal. So arrow keys should not fall out of the popover and focus get lost. Loss of focus is as bad as stealing focus unexpectedly. So arrow keys should be trapped to not have focus fall out of that modal.

HTH

[enriquesanchez]

Thank you @MarcoZehe! Your feedback is super useful.

[enriquesanchez]

There was some a11y feedback on the LinkControl component provided on #8573 (comment). Linking here for reference.

[richtabor]

@jeryj Is this still relevant? Re #50950 and the progress towards #50891