fix(#3047): Interactive elements hidden by the VisuallyHidden component don't receive Talkback virtual clicks on certain devices#3048
fix(#3047): Interactive elements hidden by the VisuallyHidden component don't receive Talkback virtual clicks on certain devices#3048majornista wants to merge 19 commits intomainfrom
Conversation
…nt don't receive Talkback virtual clicks on certain devices 🐛 Bug Report Elements like a Menu's DismissButton and the ListView's drag handle don't receive a click event when focused and triggered by Android Talkback. This seems to be device specific since it works on my Samsung Galaxy S9+ but not on other Android devices that have the same Talkback and Chrome version (e.g. Android 7.1.1 on HTC Nexus 9 using Talkback 12.1 with Chrome 100.0.4896.88). The root cause seems to be due to clip-path and/or the size of the element itself. Base reproduction with a possible fix: https://codepen.io/majornista/pen/Exorwzq?editors=1111 bug filed: https://issuetracker.google.com/issues/229646660 🤔 Expected Behavior Talkback should be able to trigger a click on a visually hidden element 😯 Current Behavior Talkback isn't able to trigger a click on a visually hidden element on certain devices 💁 Possible Solution Increasing the height/width of the visually hidden element seems to help, see code pen 🧢 Your Company/Team Adobe/Accessibility
This comment was marked as outdated.
This comment was marked as outdated.
|
Note for testing: will need to make sure that the hidden element can't be accidentally pressed now that it is 10px by 10px.. Hopefully it doesn't block presses meant for the menu/row if the user presses on the visually hidden element. |
This comment was marked as outdated.
This comment was marked as outdated.
| height: 1, | ||
| margin: '0 -1px -1px 0', | ||
| clip: 'rect(0 10px 10px 0)', | ||
| clipPath: 'inset(40%)', |
There was a problem hiding this comment.
Unfortunately due to this clipPath no longer being inset(50%) I am able to click in the top left corner of the datepicker modal and close it: https://reactspectrum.blob.core.windows.net/reactspectrum/868e245a81fbaea15da6756323a666be62a5460b/storybook/index.html?path=/story/date-and-time-datepicker--default
@majornista I think I remember you saying that this clipPath change was necessary to get your Android devices to properly click the visually dismiss button via TalkBack? If so we'll have to discuss if we think this is a big enough problem to ditch this approach. Maybe we could absolutely position the visually hidden dismiss button just outside of the Dialog, not sure...
There was a problem hiding this comment.
We may need to ditch the approach or at least modify it. I've oftentimes thought the dismiss button should just be a big hit target placed over the visible viewport dimensions, underneath the overlay.
I think we can add style={{marginBlockStart: '-10px'}} to the DismissButton within Overlays.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
LFDanLu
left a comment
There was a problem hiding this comment.
Confirmed that I'm still able to use the DismissButton via TalkBack and VO. Open to other people's opinion on the marginBlockStart style applied to DismissButton
|
|
||
| return ( | ||
| <VisuallyHidden> | ||
| <VisuallyHidden style={{marginBlockStart: '-10px'}}> |
There was a problem hiding this comment.
Open to opinions: Maybe we should open up the api so user provided styles to the DismissButton are passed to the VisuallyHidden component? Just a bit concerned that the -10px is making an assumption about the positioning of
There was a problem hiding this comment.
@LFDanLu Yeah, the -10px is based on the height of the hit target for the VisuallyHidden element, so if that were to change...
There was a problem hiding this comment.
my concern there is that no one would know what to base the value on
might it be better if we allow people to pass a ref to the target? we could watch for size changes on it and adjust accordingly
There was a problem hiding this comment.
One could pass transform: translate(0, -100%) as needed.
This comment was marked as outdated.
This comment was marked as outdated.
|
@LFDanLu Would it make sense to only change the VisuallyHidden css on Android? |
This comment was marked as outdated.
This comment was marked as outdated.
@majornista Hm, I think that would be fair, we have precedence for platform specific fixes in other places. |
This comment was marked as outdated.
This comment was marked as outdated.
LFDanLu
left a comment
There was a problem hiding this comment.
Confirmed it is working in TalkBack and VO for me. Now that DismissButton has the style prop, perhaps we should document this bug in the DismissButton docs but that can/should be followup since we need to wait for this change to be released before updating the docs.
The other docs changes should also be removed for the mean time for the above reason
packages/@react-aria/autocomplete/docs/useSearchAutocomplete.mdx
Outdated
Show resolved
Hide resolved
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Build successful! 🎉 |
| <FocusScope restoreFocus> | ||
| <div {...overlayProps} ref={overlayRef}> | ||
| <DismissButton onDismiss={props.onClose} /> | ||
| <DismissButton onDismiss={props.onClose} style={{transform: 'translate(0, -100%)'}} /> |
There was a problem hiding this comment.
Should these styles be built into VisuallyHidden? Requiring this addition is a breaking change for anyone that previously copied this example into their own component.
There was a problem hiding this comment.
It's not really a problem with VisuallyHidden. It's a problem with positioning the DismissButton so that it does not overlap behind a MenuItem in the overlay, and it depends on where the DismissButton is rendered in the DOM, before or after the Menu.
There was a problem hiding this comment.
Related comment thread: #3048 (comment)
There was a problem hiding this comment.
See similar changes in React-Spectrum components: https://github.com/adobe/react-spectrum/pull/3048/files#diff-fdb3e8acd93715a7b806be804886c9f064fc17a049f57b4cc90f690d731ad105L87-R89
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
The original problem has since been testing on a couple of Android devices, none of which have this problem. The combination of the low percentage of users (only our team has reported it so far), an existing bug filed with google, and the downsides of this suggested solution is enough to just close this issue as "won't fix". We can revisit if reported in the future. |
🐛 Bug Report
Elements like a Menu's DismissButton and the ListView's drag handle don't receive a click event when focused and triggered by Android Talkback. This seems to be device specific since it works on my Samsung Galaxy S9+ but not on other Android devices that have the same Talkback and Chrome version (e.g. Android 7.1.1 on HTC Nexus 9 using Talkback 12.1 with Chrome 100.0.4896.88). The root cause seems to be due to clip-path and/or the size of the element itself.
Base reproduction with a possible fix: https://codepen.io/majornista/pen/Exorwzq?editors=1111
bug filed: https://issuetracker.google.com/issues/229646660
🤔 Expected Behavior
Talkback should be able to trigger a click on a visually hidden element
😯 Current Behavior
Talkback isn't able to trigger a click on a visually hidden element on certain devices
💁 Possible Solution
Increasing the height/width of the visually hidden element seems to help, see codepen example.
Closes #3047
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project:
Adobe/Accessibility