iOS VoiceOver issue in Editable Combobox With List Autocomplete Example #1619
Comments
|
Wow, I'm surprised we didn't catch this. Thank you for calling it to our attention. This is perplexing. because leaving it open on blur doesn't seem like desirable behavior for desktop keyboard users. Maybe there is another way to address that. I'm surprised that VoiceOver is creating blur event by default. That also seems problematic. It doesn't seem like navigating with VoiceOver should have that kind of side effect. It definitely limits the ability of VoiceOver users to explore what is happening on screen. @sinabahram what do you think of this VoiceOver behavior? |
mcking65
added
assistive-technology-dependency
|
Definitely can't leave things positioned over the page open when users leave it. How did the 1.1 version prevent "hanging popups" for these lists? I vaguely remember a similar issue with VoiceOver years ago with autocompletes (can't recall which component explicitly) being demo'd at CSUN. Because focus was truly moving into the dropdown, that meant focus was no longer in the input itself, which... caused the dropdown to vanish. Birkir I believe demo'd it in one of the Deque rooms... might have been in 2016 even. |
|
My impression is that this VoiceOver focus/blur behavior is new, perhaps introduced in iOS 14. Or that it worked like this in an earlier iOS version, and now does again... I know that we tested the same autocompletes (MaterialUI, based on this pattern) in our current project as late as this spring and that it did not have this issue at that time. The 1.1 version is interesting on a closer look. Because it does not actually leave the popup hanging when using keyboard, it closes on blur the same as the 1.2 pattern. But when you are using VoiceOver it does leave the listbox open. Perhaps someone can look into what makes the two patterns different. |
|
@cookiecrook Do you know anything about the described focus/blur behavior in recent iOS VO? |
|
Some more info. It appears the differences in behavior between the 1.1 and 1.2 patterns comes from how they are hiding the listbox. The 1.1 pattern is hiding the listbox using a TAB key listener, and an outside click listener. Neither of which are triggered by VoiceOver swipes and exploration. The 1.2 pattern is hiding the listbox using a blur event listener, which does get triggered by VoiceOver. |
|
@mcking65 Do you have any updates regarding this issue? |
|
What is the status for this? Is there any investigation or other actions? |
|
@useit-consulting, thank you, thank you for this analysis.
I don't see a problem with working around the VoiceOver behavior by changing the new examples to use these techniques for hiding the listbox. @jongund, @carmacleod, do you agree? @spectranaut, could you put together a PR to address this? Nonetheless, this still seems like a work-around that should not be necessary. @cookiecrook, still wondering if you see this as a VoiceOver bug? |
Kinda. Blur would be better, because there are more ways to blur than just TAB key. For example, Ctrl/Cmd+L goes to the browser's URL bar, and I would expect the combo to close if I typed that. Also, if I typed Ctrl/Cmd+F to find things on the page. Similarly, for any of the browser's Tab management shortcuts, like Ctrl/Cmd+T for opening a new Tab, Ctrl/Cmd+1 for switching Tabs, etc. And obviously, we need to be sure to support Esc. So if we go that route, I think we would need a big note and/or comment saying that we are working around a VO iOS bug/feature. |
|
@carmacleod wrote:
I would not necessarily expect opening a new tab, moving to a new tab, or going to the address bar to close an open combobox. I wouldn't be surprised if it did, but I wouldn't expect it. In some cases, I might be bothered by it. If I were navigating through options in a combobox and had a question about one of the options, I might open a new tab to look up something. It would bug me if I were to have lost my spot in that case. So, keeping it open unless the user acts to close it might be a feature.
We already have specific escape behaviors documented, coded, and tested.
If Apple says this is expected behavior and has strong rationale for leaving it as is, we could potentially document it, but we wouldn't couch it as a work-around. However, speaking personally, this really feels like an iOS bug. |
|
This example also appears to be broken with Full Keyboard Access on iOS. For example, I can't arrow through the popup selections. When using typeahead, I also can't select them with the Space Bar – example only registers the Windows-style use of the "Enter" key, but not a Mac user's expectation of Space Bar. It's difficult to determine if there is a problem with VoiceOver given that full keyboard access doesn't work in the example. Regarding Matt's comment that firing focus at all seems like a VO bug: Anything that moves focus (including but not limited to VoiceOver, Full Keyboard Access, etc.) should cause focus events. It was this way for most of iOS. Those events fell out of WebKit due to a regression in iOS 13 (maybe iOS 12), and the bug was resolved to add them back in with WebKit in iOS 14. So I don't consider focus events to be a bug in iOS. Blur on the previously focused element will be fired once the cursor moves to the next focusable control. |
|
@cookiecrook commented
Testing this out, I observe that iOS VoiceOver is silent when arrowing down. Is it not supporting aria-activedescendant?
I notice that on my macOS, both enter and space select items from native popups. Maybe we should make the combobox examples work that way. One question would be whether we do so for all platforms or just mac and iOS.
If default VoiceOver behavior is always going to be to move focus, and thus trigger blur, when moving its reading cursor, even when moving it via touch, then we're going to need to revisit every use of blur in all patterns. If we're lucky, it's only comboboxes and menu buttons that are potentially problematic, but I have a feeling there could be some others too, maybe listbox and tree.
Are you open to a deep dive on this topic to discern whether or not is really desirable for touch-based screen readers to so tightly tie screen exploration to document.activeElement and related events? Another concern is users getting lost when actions are not symetric. If a right swipe causes a blur that hides or collapses something, then a left swipe will not return them to where they were. In some circumstances where this could happen, one potential remedy might be to declare all popups modal. Then, Touch screen reader users couldn't accidentally swipe out of them. That is how the iOS native versions of some of these components work. The huge downside there is that we'd need a focusable close element, and that is not present in web components designed for desktop use with mouse and keyboard. One possible remedy for that might be for touch screen readers to automatically turn the inert background into a focusable close element that is at the start or end of the swipe order. |
PR here for removing blur event and adding closing on click outside of widget: #1699 |
|
As I investigate further, there are some non-touch screen reader accessibility reasons for not using blur on the textbox to collapse the combobox. For example, VoiceOver on macOS and NVDA both move focus when reading. If you run NVDA, expand the combobox, then switch to browse mode to explore, the combobox will collapse as soon as you move the browse cursor to the states button. So, you can't explore the popup in browse mode unless you first move focus into the popup. Even then, if you accidentally move the browse cursor out of the popup, you will lose it. The same kind of thing happens with Narrator. However, there are several other issues with the Narrator behavior that feel like potential bugs, or maybe more accurately, issues with the Narrator design. Some people might categorize these as extreme edge cases. At least in the case of JAWS and NVDA, the expectation has always been that users use the combobox in forms or focus mode. However, partly because of the prevalence of touch screen readers, I am no longer convinced that is a reasonable expectation. There are increasing numbers of people who learn on touch devices first, and that materially impacts how they operate. |
|
Please, everyone, have a look at the preview in Valerie's PR #1699. It is working for me on iOS. Although, I don't understand why VoiceOver is not focused on the combobox input after a value is chosen from the list. Focus is being correctly set there. |
|
@mcking65 wrote:
Of course.
I think its reasonable to keep the examples working with blur and focus, with some adjustments. When I've used this technique before, the blur event handler would start a timeout (maybe 100ms, or maybe even as long as 1s), that could be cancelled by a subsequent focus event in another relevant part of the control. For example, the field losing focus would not cause the menu to be hidden, because the first result in the menu would immediately be focused, and therefore clear the "close menu" timeout.
If I am understanding this correctly, it's not a fundamental flaw in the widget... Perhaps just a usability problem in the implementation? By adjusting the timing of the behavior and the relative DOM proximity of the field and menu, perhaps this can be resolved. |
|
@mcking65 It would be nice to update the pattern and propagate the workaround to the third party libraries that are currently experiencing this bug. |
…better iOS compatibility (pull #1699) Resolves #1619. With VoiceOver running in iOS, moving screen reader focus moves browser focus, which of course triggers blur. The combo text input was closing the popup when it was blurred. Thus, VO users on iOS could not get to the popup. This commit removes use of blur and instead uses only mouse and keyboard events to determine when to close the popup. Co-authored-by: Jon Gunderson <[email protected]>
|
@useit-consulting, I apologize for the long delay here! Thank you very much for raising this issue and again thank you for the analysis that pointed us to the fix. |
I'm encountering a major focus-related issue with the Editable Combobox With List Autocomplete Example and iOS VoiceOver. It makes the component inaccessible for iOS VoiceOver users.
There's an active discussion over at MaterialUI where I've provided some videos of the effect. But since the effect also happens in this APG pattern, maybe it should be addressed here.
In short the problem is this:
Swiping through the page or using explore-by-touch with VoiceOver triggers focus and blur events.
The listbox is closed on textfield blur.
As a result, the user cannot reach the contents of the listbox, since the listbox closes automatically once you start searching for it.
I've tried swiping backwards from the keyboard, closing the keyboard with the keyboard "Close" button or using explore-by-touch. In all instances, the listbox disappears before I can interact with it.
Device details
Tested using iPhone SE and iOS 14.1 in Safari and Chrome
Other info
This issue is not present in Android Talkback + Chrome. It does not appear that Talkback triggers focus/blur events the same way VoiceOver does.
The issue is also not present in the older APG 1.1 pattern List Autocomplete with Manual Selection
I believe the difference is that the 1.1 pattern keeps the listbox open on blur, while the 1.2 example closes automatically. So a possible solution might be to keep it open like the 1.1 version.
The text was updated successfully, but these errors were encountered: