Accessibility improvements

[aryanchoudharypro]

What is it?

• Bugfix (user facing)
• Feature (user facing) ⚠️ Your PR must target the refactor branch
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

This PR significantly improves the application's accessibility for screen reader (TalkBack) users without affecting the visual UI for sighted users.

• Stream Items: Implemented AccessibilityDelegate in StreamMiniInfoItemHolder. This exposes the long-press context menu options (Enqueue, Download, Share, Play in Background, etc.) as native Accessibility Custom Actions. Users can now swipe to select an action rather than using the "double-tap and hold" gesture.
• Player Controls: Added missing android:contentDescription attributes to the queue control buttons (Repeat, Shuffle, Rewind, Fast Forward). These buttons previously read as "Unlabelled" to screen readers.
• Cleanup: Set android:importantForAccessibility="no" on list item thumbnails. This reduces navigation clutter, as the list item itself already contains the title and click action.

Before/After Screenshots/Screen Record

No visual changes. These changes affect Accessibility services (TalkBack) behavior only.

Fixes the following issue(s)

• Fixes #

Relies on the following changes

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR. You can find more info and a video demonstration on this wiki page.

Due diligence

• I read the contribution guidelines.
• The proposed changes follow the AI policy.
• I tested the changes using an emulator or a physical device.

[TobiGr]

Thank you for the PR!

I made a few changes to deduplicate the code which was mostly copied from StreamDialogDefaultEntry initially.

This is good to go once my question below is answered.

[TobiGr]

@Stypox I am not quite sure about the change I made here. Is the check even necessary anymore because we are now using the activity? Should fragementActivity.isDestroyed() or fragementActivity.isFinishing() be used instead? The check was initially introduced to ensure that opening the dialog would not lead to a crash when the fragment was closed while loading the fetching the required info, e.g. by going back.

[aryanchoudharypro]

@TobiGr Thanks for the review and the cleanup! I appreciate you handling the deduplication!

[Stypox]

Thank you for this! I would definitely merge points 2. and 3. Regarding point 1., however, I have some reservations, because of various reasons:

• Now the accessibility menu is implemented only for StreamInfoItemHolder. This means that streams in history or in local playlists won't have it. And neither will playlists and channels.
• Unfortunately the item actions code is a bit spread out everywhere and is already quite complicated. For a proper implementation the logic for which items to show should be unified (e.g. instead of duplicating the if (holder.isPlayQueueReady()) or if (!StreamTypeUtil.isAudio(item.getStreamType())) checks).
• Doing significant/complicated changes to the menu system on the dev branch, and putting effort into making it work well, is not worth it imo, considering that we are going to throw away this code soon anyway.
• With the new implementation of the long press menu in Redesigned long press menu #12032 it should be much easier to easily add accessibility menus to all info items in all of the app (i.e. videos, channels, playlists) without repeating any logic. It would be great if @aryanchoudharypro you could implement the accessibility menus in Compose after Redesigned long press menu #12032 gets merged.

[aryanchoudharypro]

Thank you for this! I would definitely merge points 2. and 3. Regarding point 1., however, I have some reservations, because of various reasons:

• Now the accessibility menu is implemented only for StreamInfoItemHolder. This means that streams in history or in local playlists won't have it. And neither will playlists and channels.
• Unfortunately the item actions code is a bit spread out everywhere and is already quite complicated. For a proper implementation the logic for which items to show should be unified (e.g. instead of duplicating the if (holder.isPlayQueueReady()) or if (!StreamTypeUtil.isAudio(item.getStreamType())) checks).
• Doing significant/complicated changes to the menu system on the dev branch, and putting effort into making it work well, is not worth it imo, considering that we are going to throw away this code soon anyway.
• With the new implementation of the long press menu in Redesigned long press menu #12032 it should be much easier to easily add accessibility menus to all info items in all of the app (i.e. videos, channels, playlists) without repeating any logic. It would be great if @aryanchoudharypro you could implement the accessibility menus in Compose after Redesigned long press menu #12032 gets merged.

Hi, yes, i can do it for the Compose menues as well. The architecture of those also seems much nicer.