TalkBack Announces Items in the Action Menu for "Multi select" Twice

[VoidCrater]

Checklist

• I have used the search function for open and closed issues to see if someone else has already submitted the same bug report.
• I will describe the problem with as much detail as possible.
• If the bug only to occurs with a certain podcast, I will include the URL of that podcast.

App version

3.1.1

Where did you get the app from

Google Play

Android version

Android 12

Device model

Nokia 5.3

First occurred

No response

Steps to reproduce

1. With TalkBack turned on, go to "Subscriptions" screen or any other screen where you can select multiple items, and double tap and hold on an item, then double tap on "Multi select"
2. Find the unlabeled actions button at the end, and double tap on it
3. TalkBack's focus should be on the last item in the menu, swipe left and you'll hear the same action repeated the second time. For example, if the focus was on the "Delete" button, swiping left again will make TalkBack announce "Delete" again

Expected behaviour

1. When making multiple selections with TalkBack turned on, the "actions" button should have been announced as "actions button".
2. In the actions menu, each item should be announced only once by TalkBack, not twice.

Current behaviour

No response

Logs

No response

[rahul13agrawal]

I have gone through this issue. This is the functionality of the library that is used in AntennaPod
com.leinardi.android:speed-dial:3.2.0

[TacoTheDank]

@ByteHamster (ping)

Expected behavior 2 is not a bug, but a feature. I tested Talkback myself on my Android 12 device, and as far as I can tell, this is intentional. Both the button themselves and their side labels are meant to be pressable (and are distinct from one another). When you are swiping left, the Talkback shifts focus from the button to its label, and describes it as such (e.g. when focused on the Remove Podcast button, it is described as "Remove podcast button", and when swiping left, Talkback then shifts to the button's label, which is described as "Remove podcast").

As for expected behavior 1, this looks to be fixed upstream in SpeedDial 3.3.0: leinardi/FloatingActionButtonSpeedDial@c85710e (see commit and corresponding issue). I will test to confirm this, and then make a PR. (Update: the new version does not fix this. I've opened an issue.)

[TacoTheDank]

Oh, I also found an additional bug in the Subscriptions page: the "add podcast" FAB is still visible underneath the SpeedDial main FAB. It should be gone when the "multi select" option is active. I will include this fix.

[TacoTheDank]

Also, regarding "TalkBack's focus should be on the last item in the menu," this is actually not intended behavior: leinardi/FloatingActionButtonSpeedDial#167. This has also been fixed in SpeedDial 3.3.0.

[VoidCrater]

@TacoTheDank

Expected behavior 2 is not a bug, but a feature. I tested Talkback myself on my Android 12 device, and as far as I can tell, this is intentional. Both the button themselves and their side labels are meant to be pressable (and are distinct from one another). When you are swiping left, the Talkback shifts focus from the button to its label, and describes it as such (e.g. when focused on the Remove Podcast button, it is described as "Remove podcast button", and when swiping left, Talkback then shifts to the button's label, which is described as "Remove podcast").

I'm a user who primarily relies on TalkBack to interact with Android, and I believe TalkBack announcing the button for the action as well as the label for it is just redundant. Instead of swiping once to get to the next action in the menu, TalkBack users have to swipe twice. I think a better approach would be to make TalkBack announce just the button and ignore the label for that button all together. This will make the experience of interacting with the menu seamless.

[TacoTheDank]

@VoidCrater I agree it would make TalkBack more seamless, but I'm not sure if ignoring the label would actually be possible, considering the SpeedDial library's design (and the design of the Google Material library it's built upon).

I will have to check.

[ByteHamster]

I reported the issue that things are announced twice to the upstream library: leinardi/FloatingActionButtonSpeedDial#193

[ByteHamster]

Given that we now have 3 issues with that speed dial button library, I wonder if we should migrate away from it. The more "standard Android" way to do multi-select is to have the actions in the top bar anyway. So this would remove a dependency causing problems and would make AntennaPod more in line with other apps. What do you think @keunes @TacoTheDank?

[keunes]

We really have a big list of possible actions. I doubt we could make it work nicely in the top bar. Also, the top bar cannot host descriptive visual labels, while the icons aren't always that clear.

So I think I'd be inclined to keep it, and hope that this bug can be addressed upstream.

[ByteHamster]

The items in the overflow menu of the top bar have texts, so it is the same as on the current version. Using the overflow menu needs the same number of taps as before. For items we show as icon (obvious ones like "download") it would be one tap less.

I think doing it the same as other apps is quite an important thing. I have never seen any other app solve multi-select like we do.

[keunes]

Can you maybe create a new issue so we can discuss further? I think there's merit to continue discussing it but for findability it's probably better to take it separate from this bug report.

[TacoTheDank]

Continued in #6948.

[ByteHamster]

Because we plan to switch away from the multi-select library anyway (#6948, as TacoTheDank already commented), we don't need to keep this open.