BUG - sev-2 - All - Keyboard navigation on subtasks, large panels, cancel popups often goes to hidden layers, gets stuck

[TKDickson]

What happened?

Keyboard navigation on both iOS and Android will navigate 'behind' the panel on subtasks, large panels, and cancel popups. Often on iOS you can still get to the desired content/actions; on Android it's more difficult (and sometimes not possible, depending on the screen).

Here's updating contact info on Android, with keyboard. The times when I'm 'stuck' for a long while and then magically get unstuck, it's because I've used my finger to tap directly onto the screen (obviously not a viable workaround for users).

Specs:

• Device:
• OS:
• User Account:
• Accessibility State: Turn on Keyboard full access for your device

Steps to Reproduce

(See video in description, above)

• Turn on keyboard full access for your device (you can log into the mobile app first if you like)
• Start any workflow - editing and saving contact info is a good proxy - in which you're going to have large panels, fullscreen subtasks, or native popups -- layers on the UI where typically there's a visible "thing behind" and "thing in front"
• Attempt to do that workflow with a keyboard. Some of them are possible to 'get into' the UI in front with things like "shift+tab 20 times to get onto the popup"; others are not possible to get the keyboard onto at all.

Desired behavior

Navigation/Focus should be on the 'top' layer of the UI (large panel, native cancel popup, etc), not allowed to go behind it, or even worse - trapped behind it.

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See Bug Tracking for details on severity levels

• Impact: High
• Frequency: Low

• 2 - High

Linked to Story

Screen shot(s) and additional information

Full JSON response for services related to issue (expand/collapse)

Ticket Checklist

• Steps to reproduce are defined
• Desired behavior is added
• Labels added (front-end, back-end, global, Health, relevant feature, accessibility, etc)
• Estimate of 1 added (for front-end tickets)
• Added either to the relevant feature epic (if found during new feature implementation), or the relevant team's bug epic (Global, Health & Benefits, API, QART)

[alexandec]

I tested this with iOS 18 and I'm still seeing the issue. I can reliably use the tab key to place focus on the Cancel button, but using the arrow keys frequently navigates behind the large panel in front.

[alexandec]

Some background info on keyboard navigation:

• It's possible for VoiceOver/TalkBack focus to work fine, but for keyboard navigation the focus may not work correctly on the same elements due to a difference in implementation between screen reader and keyboard navigation
• We can't detect whether the user has FKA (Full Keyboard Access) enabled on iOS so we can't enable a workaround only for FKA
• Any keyboard navigation workarounds must be carefully tested with screen readers to ensure they don't introduce regressions
• See the comments on #9474 for additional investigation and info on keyboard navigation

[rbontrager]

@theodur Your solution caused another issue. Basically while you can now navigate to the street address line 1 in android in your build, you still can't get into and edit the field with the keyboard.

[theodur]

@rbontrager When I was looking into the issue a while ago, it seems like this is a known issue with React Native and Android, where physical keyboard detection isn't picked up on Android.

https://reactnative.dev/docs/textinput#onkeypress

Note: on Android only the inputs from soft keyboard are handled, not the hardware keyboard inputs.

facebook/react-native#30464

This will probably need its own ticket to go in depth with the Android text input issue. For now, the changes in my PR at least prevent users from getting stuck on pop-ups, large panels, etc. and allows them to navigate through the whole form which is an improvement from the current experience.