Fix UrlInput combobox to use the ARIA 1.0 pattern.#47148
Conversation
|
Size Change: -15.2 kB (-1%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in e32866a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3931843625
|
alexstine
left a comment
There was a problem hiding this comment.
Stupid Voiceover. This is why no one can ever move forward, Apple lags years behind in basic accessibility. It generally is not a problem in native applications but comes back to hurt us big time on the web. So annoying. This has also become much worse in IOS 16 for mobile devices. Wish Apple would bring back their old values.
My political comments out of the way, this looks good from a code perspective. I trust your judgement in testing @afercia, thanks for catching this.
| // Search Input UI. | ||
| const searchInput = screen.getByRole( 'combobox', { name: 'URL' } ); | ||
|
|
||
| expect( searchInput ).toBeInTheDocument(); |
There was a problem hiding this comment.
Does it make sense to change this assertion to use toBeVisible()? I've found this to be a bit more specific query, since toBeInTheDocument() will be truthy if the element is not accessible to the user at all.
| expect( searchInput ).toBeInTheDocument(); | |
| expect( searchInput ).toBeVisible(); |
There was a problem hiding this comment.
Makes sense. There are a few more occurrences of toBeInTheDocument(). Some of them use not and they actually test for some elements to not be in the DOM. I guess the other ones should be changed to toBeVisible().
| const searchInput = screen.getByRole( 'combobox', { name: 'URL' } ); | ||
|
|
||
| expect( searchInput ).toBeInTheDocument(); | ||
| expect( searchInput ).not.toHaveAttribute( 'aria-controls' ); |
There was a problem hiding this comment.
I don't see a good reason to have this assertion in place. I think we can remove it.
| expect( searchInput ).not.toHaveAttribute( 'aria-controls' ); |
There was a problem hiding this comment.
I'd like to make sure aria-selected is set only on the highlighted item and omitted from all the other items. The current usage is wrong and I'd like to to avoid future misuse. I'd agree it's best to move this to a separate test though.
There was a problem hiding this comment.
I understand. thanks for clarifying. I guess it's worth adding some context as a comment to the test then 👍
There was a problem hiding this comment.
My bad, I see now you mentioned the assertion for aria-controls, not the one for aria-selected. Will add comments to clarify both.
|
Thanks everyone for the feedback. Everything is green, merging. |
What?
Fixes #47147
Safari and VoiceOver don't read the UrlInput combobox suggestions. To make the combobox implementation be broadly supported, there's the need to stick to the 'old' ARIA 1.0 pattern.
/Cc @tyxla @mirka
Why?
The combobox implementation needs to be consistent across all the codebase and use the most broadly supported ARIA pattern.
How?
aria-ownswitharia-controlsinURLInput#43278 changingaria-controlsback toaria-ownsaria-selected, as it needs to be set only on the highlighted itemTesting Instructions
Optionally test with the most common browser / screen reader combinations. I tested with:
Update: note to clarify that Safari and VoiceOver are buggy anyways. When testing, you may notice some weirdness in the way the options are announced e.g.:
{option name}, clickable{option name}, selected, (1 of n), completion selected(this is the expected behavior)Testing Instructions for Keyboard
See above.
Screenshots or screencast