UrlInput: Stick to the ARIA 1.0 pattern

[afercia]

Description

I was wondering why Safari + VoiceOver fail reading the options of the UrlInput combobox while they do announce the options of the Tag suggestions. Screenshot:

Turns out the input field of UrlInput uses aria-controls while the one of the Tag suggestions uses aria-owns. This was changed in #43278 and only for the UrlInput component.

Please notice that making a change that may look trivial can actually have a huge impact on assistive technology. Also, Safari + VoiceOver are known to be buggy with comboboxes.

It's very, very, important to actually test the impact of such changes on the most common browsers / screen reader combinations. Even the most simple changes need to be testsd.

TL;DR

The change in #43278 was made following on this comment, based on a recommendation on the MDN combobox documentation:

Note: In older ARIA specs, this was aria-owns rather than aria-controls, so you may see aria-owns in older combobox implementations. The aria-owns in the code should be updated to aria-controls!

Unfortunately, that's inaccurate.

It is true the newer ARIA specs recommends aria-controls. However, the combobox ARIA pattern evolved over time across the ARIA 1.0, 1.1, and 1.2 specs. It is important to note that the HTML structure itself changed, together with the usage of some aria-properties. To recap:

ARIA 1.2

It's still a 'Candidate Recommendation Draft', stuck on 08 December 2021. As such, it's not a official recommendation and it's not guaranteed to be implemented by vendors.
It provides an interesting note at https://www.w3.org/TR/wai-aria-1.2/#combobox

The structural requirements for combobox defined by this version of the specification are different from the requirements defined by ARIA 1.0 and ARIA 1.1:

• The ARIA 1.0 specification required the input element with the combobox role to be a single-line text field and reference the popup element with aria-owns instead of aria-controls.
• The ARIA 1.1 specification, which was not broadly supported by assistive technologies, required the combobox to be a non-focusable element with two required owned elements -- a focusable textbox and a popup element controlled by the textbox.
• The changes introduced in ARIA 1.2 improve interoperability with assistive technologies and enable authors to create presentations of combobox that more closely imitate a native HTML select element.

Here's the HTML example in ARIA 1.2:

<input type="text" id="tag_combo"
      role="combobox" aria-autocomplete="list"
      aria-haspopup="listbox" aria-expanded="true"
      aria-controls="popup_listbox" aria-activedescendant="selected_option">
<ul role="listbox" id="popup_listbox">
   <li role="option"> ...

Again, we can't use this pattern.

ARIA 1.1

ARIA 1.1 is the current official recommendation, dated 14 December 2017.
As mentioned in ARIA 1.2, the 1.1 combobox pattern was not broadly supported by assistive technologies, Basically it doesn't work well and we can't use it.

Here's the HTML example in ARIA 1.1, where a div element 'owns' both the input and the listbox (via nesting and aria-owns):

<div aria-label="Tag" role="combobox" aria-expanded="true" aria-owns="owned_listbox" aria-haspopup="listbox">
    <input type="text" aria-autocomplete="list" aria-controls="owned_listbox" aria-activedescendant="selected_option">
</div>
<ul role="listbox" id="owned_listbox">
    <li role="option">Zebra</li>
    <li role="option" id="selected_option">Zoom</li>
</ul>

Again, we can't use this pattern.

ARIA 1.0

This is an old pattern but it's the only one that is currently broadly supported. It uses aria-owns in the input field.

Here's the HTML example in ARIA 1.0:

<input type="text" aria-label="Tag" role="combobox" aria-expanded="true"
  aria-autocomplete="list" aria-owns="owned_listbox" aria-activedescendant="selected_option">
<ul role="listbox" id="owned_listbox">
  <li role="option">Zebra</li>
  <li role="option" id="selected_option">Zoom</li>
</ul>

By restoring aria-owns, Safari + VoiceOver magically announce the options again.

Aside

There's one more detail that needs to be improved.
The aria-selected attribute needs to be rendered only on the 'highlighted' option and omitted from all the other options. The only allowed usage of aria-selected with a value of false in an ARIA listbox is when the Listbox allows selcting multiple items.

To clarify, here's a screenshot from the W3C ARIA Authoring Practices Editable Combobox with List Autocomplete:

Step-by-step reproduction instructions

• edit a post
• use Safari and VoiceOver
• add a link to a word in a paragraph
• type 'hello' in the URL input search to get some link suggestions
• use the Down and Up keys do navigate through the suggestion options
• observe VoiceOver doesn't announce the options
• make sure the settings sidebar displays the Post tab
• click to add a Tag to the post
• type something in the 'Add new tag' field to trigger the list of suggestions
• observe VoiceOver does announce the options

Note: as mentioned above, Safari and VoiceOver are buggy anyways. When testing, you may notice some weirdness also when using the Tag selector. They announce things differently or in a buggy way e.g.:

• sometimes they just announce {option name}, clickable
• sometimes they announce {option name}, selected, (1 of n), completion selected (this is the expected behavior)
• sometimes you may need to delete one of the typed characters and re-type it again to make VoiceOver announce the options

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes