BUG - sev-3 - Android - On some devices, alert and expand/collapse components have terrible screen reader swipe order in Android 14

[TKDickson]

What happened?

On my Pixel running Android 14 (but not on my OnePlus running Android 11 - dunno if it's OS-specific, device-specific, text-size-specific, etc), many alerts and expand/collapse components have a nonsensical swipe order for screen reader users. Basically - a bunch of content (from somewhere in the screen, not necessarily the top of the content) is chunked together, and put very early on in the component swipe order. In the case of expand/collapse component, that swipe order is unfortunately BEFORE the expanded version of the component's announcement, so only swiping forwards users will miss the information.

Here's the LOA gate screen, android only, I'm swiping forward only, until I go backwards to 'find' the entire first half of the content backwards in the swipe order from the expanded component.

Here's the meds not authorized alert. I also saw this swipe order issue on the Rx transferred med details banner.

I checked a Aug 21 develop build (before the design system alert component changes were in develop), and was able to reproduce the issue with both screens I tried (LOA gate and RX transferred med details banner) so it doesn't seem to be related to the alerts DS implementation (the only recent thing I know of, that might have changed this behavior)

Specs:

• Device: Pixel
• OS: Android 14
• User Account:
• Accessibility State: TalkBack on

Steps to Reproduce

• Install a new version of the app on your device (so you'll hit the LOA gate screen)
• With screen reader on, tap the "Sign in" button, then expand the component near the bottom of the screen
• Swiping forward after expanding, notice how you skip the first paragraph and several bullets of information to go most of the way through the content
• Swipe backwards, to find all of that content one swipe BEFORE the expanded component, in swipe order
• Repeat as desired with all other listed components, in the description.

Desired behavior

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See Bug Tracking for details on severity levels

• Impact: High Low
• Frequency: High Low

• 3 - Low
• 2 - High
• 1 - Critical

Linked to Story

Found while testing, but not caused by, #5779

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)

[TKDickson]

@Sparowhawk this is a draft ticket/not ready for pending handoff. I'm happy to leave it in that column for now (because IDK why you moved it), but there's nowhere near enough info in this ticket for a handoff yet. Hence - no severity label, details to reproduce, etc.

[jennb33]

12/11/2024 - @kellylein @timwright12 @oddballpete @Eallan919 @ATeal @TKDickson The MFS team will be taking this ticket into Sprint 7, (12/14/2024-12/27/2024)

[brea11y]

@jennb33 – Just a heads up that this ticket isn't workable until an accessibility review and recommendation is completed. I have it scheduled to do that part this sprint, but a lot has been added to my list in the last couple of days and I may not get to it. If I don't get to it by EOD Monday, I'll comment here and let you know. In the meantime, I would recommend updating your list to reflect that this one might not be one that you guys can take on without that step being completed. Thanks so much!

[jennb33]

Thank you, @brea11y - I will remove this from our Sprint 8 plan for now, and we can touch base when you're done to get it back into our schedule. Much appreciated for the context.