BUG - sev-3 - Android - TalkBack: Unable to use tap to focus on snackbar if other focusable content is behind snackbar

[TKDickson]

What happened?

On Android, I'm unable to use tap to focus on snackbar if other focusable content is behind snackbar - here's a video of me repeatedly attempting to tap directly on the snackbar & getting redirected to the content behind it.

Once I've scrolled enough that there are no focusable elements behind the snackbar, tap will focus on it. And I can still swipe to the snackbar as well.

Using a tap to get focus & readout on a specific element is a characteristic workflow of a sighted user with screen reader on, in case anyone was wondering

Specs:

• Device:Pixel 6 on Android 13, n100 on Android 11
• OS:
• User Account:
• Accessibility State:

Steps to Reproduce

Happens in both pre-Nav, and post-Nav, versions of the app

1. Change the display/font size to largest possible
2. Log into a user that has letters
3. Turn on talkback.
4. Change the mailing address in letters. Try clicking on the mailing address saved snackbar and notice that is isn't clickable.

Desired behavior

Should be able to get focus to snackbar by tapping on it, regardless of what's behind it, like I can in iOS.

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See Issue Tracking for details on Severity Levels

• 3 - Low

Linked to Story

Screen shot(s) and additional information

Ticket Checklist

• Steps to reproduce are defined
• Desired behavior is added
• Labels added (front-end, back-end, feature, bug)
• Estimate of 1 added

[TKDickson]

QA Estimate: 1 point

[Sparowhawk]

@rbontrager @bischoffa Can you confirm if this is still an issue? This library was updated in may as part of the dependency updates and I know it should have addressed the other bug in this sprint.

[bischoffa]

@Sparowhawk   @rbontrager I did not plan any QA points for bugs this sprint in order to make sure you aren't overwhelmed with QA testing work. I am okay for this to be retested next sprint if there is no time this sprint.

[rbontrager]

@Sparowhawk I can confirm this is still an issue. I've update the steps to reproduce as well so hopefully you can see it.

[alexandec]

I can halfway reproduce this on Android. I found that I was able to get the correct focus by tapping on elements inside the snackbar. However if I tapped on the empty part of the snackbar, focus would fall through to the button underneath. Here's how it looks for me:

snackbar-focus-talkback.webm

Ideally even tapping on the empty part of the snackbar would place focus on the snackbar, not what's underneath.

We are using react-native-toast-notifications to show the snackbar. I looked at the options available in that library but none of them appear to address this issue. I also tried adding a zIndex property and toggling accessible={true} but those didn't help.

I found an issue which describes our exact problem: facebook/react-native#29557. A potential solution described there is to wrap the whole snackbar in a TouchableOpacity component, essentially making it one big button. I tried adding this as a wrapper around the snackbar in SnackBar.tsx:

<TouchableOpacity style={confirmBtnStlye} accessible={true} accessibilityRole={'button'}>
  ...
</TouchableOpacity>

This technique did block focus from falling to the items underneath the snackbar on Android. However, on iPhone, the buttons and text inside the snackbar were no longer treated as separate elements -- the whole snackbar was one big button. I don't think this method of placing buttons inside buttons is a good one because it introduces new a11y problems which are worse than the problem it solves.

It's possible there is some other method of resolving this, but it's also possible that TalkBack and React Native don't play as well together as iOS and React Native in this scenario. Based on my discovery so far, I believe this bug will be difficult to fix. It may even require switching from Toast to a different library, or creating our own. I will increase the estimate accordingly.

[alexandec]

@bischoffa I wrote up my findings, increased the estimate, and moved this to the backlog.

[TimRoe]

Not sure if the Global team wanted to pick this up sooner or wait until integrating the Snackbar component from the design system, but a simple fix was found for this issue that should carryover to flagship fairly easily (a 1 pointer, mostly just testing) if desired to fix sooner with that knowledge.

Edit:
@ajsarkar28 for awareness.

[timwright12]

@alexandec is this still an issue or are we just swapping out with the design system component?

[alexandec]

@timwright12 it's still an issue. It's more of a prioritization question of whether to fix our component first, then replace it with the design system component which also has the fix, or just wait until we do the replacement.

[TimRoe]

FWIW: The design system Snackbar component has since been completed and is ready for implementation whenever flagship is ready to prioritize.

[timwright12]

Ok, I'm going block this ticket behind #9630 so we can circle back afterwards

[jennb33]

12/16/2024 - Per @kimmccaskill-oddball, this is blocked by 9630, which is in PR. @oddballdave said that 9630 is approved by Eng, needs QA. Jennifer to send to Don.

[TKDickson]

@kimmccaskill-oddball here's a copy of the video you should be able to view https://github.com/user-attachments/assets/1fc8ccf4-d7f9-4153-b0e4-e1a33f01c7b5

[jennb33]

12/18/2024 - @kimmccaskill-oddball reports that, while working with this in tandem with #113, he was able to reproduce the issue. He's running it through an emulator, reviewing Dave's PR.

[kimmccaskill-oddball]

@timwright12 @TimRoe @TKDickson after pulling down Daves changes for his fix on #9630, the behavior was that the tap to focus is available on both the text of the snackbar and the Dismiss button of the snackbar, but not the snackbar container itself. In terms of functionality, this is a thumbs up from me, but want to double check with yall.

[jennb33]

12/18/2024 - @kimmccaskill-oddball I will also request that Don reviews this ticket, in OCTO Slack. Thank you!

[kimmccaskill-oddball]

@jennb33 I don't have a PR up for this. The fix would just be dependent on Dave's PR!

[jennb33]

1/2/2025 - Moved ticket to Sprint 8 to be completed. Pending 9630 complete, then this work will also be completed. No separate PR required.

[jennb33]

1/9/2025 - this work will be complete, once 9630 is approved and deployed. Blocked pending 9630 completion. Rolling this ticket to Sprint 9.