Accessibility bug report: Search results list is invisible with VoiceOver on macOS

[nickinesio]

Hello,
I am a blind user utilizing the VoiceOver screen reader on macOS. I am reaching out to report a critical accessibility barrier in the current version of aMule.
In the "Search" tab, once a search is completed, VoiceOver is completely unable to detect or interact with the search results table. It reads the total number of results, but the list itself remains invisible to the keyboard navigation, making the software unusable.
Furthermore, in the Preferences window, VoiceOver only shows the "General" options. The vertical sidebar that contains the other categories (Connection, Security, etc.) is fully inaccessible, preventing users from changing tabs or enabling external connections to use aMuleGUI.
Could you please look into the wxWidgets components accessibility mappings for macOS in future updates?
Thank you for your help and for keeping the project alive.
Regards.

[got3nks]

Thanks for the detailed report — both issues are confirmed.

For the Preferences sidebar: we tried two small targeted fixes on macOS, neither helped. The cause is one layer deeper — the underlying widget library (wxWidgets) isn't fully exposing the categories list to VoiceOver on macOS. The most realistic path forward is to swap the sidebar for a different widget type that bridges more completely to macOS accessibility. That would change the look slightly (the sidebar would gain tree-style expand/collapse arrows) but preserve the vertical layout, and would carry over to Windows and Linux too. It's a non-trivial refactor but it's tractable.

For the search results list: the widget is fully custom-drawn and has no native counterpart on any platform, so VoiceOver, Narrator and Orca all see nothing. Fixing this requires either implementing the accessibility bridge ourselves in aMule, or replacing the custom list with a native one (which would lose features like custom row colors). This is significantly more work and we don't have a clean path yet.

No timeline on either fix, but the Preferences-sidebar swap is the more tractable of the two and we'd start there. Tracking both in this issue. Thanks again for taking the time to report this — accessibility gaps are easy to miss without users testing with AT.

[nickinesio]

Thank you for this incredibly fast and amazing feedback! It's wonderful to see such commitment to accessibility. Please note that **I do not speak English and I use an AI to translate my messages and help me with my technical research**. The suggestions I share are the result of my research with the AI to find the best cross-platform solutions, **but there may be errors — I invite you to verify these technical paths before implementing them**. ⚠️ **Important: I want to insist one last time that the technical advice I give does not come from me, but from the AI that advises me.** I only transmit information researched with the AI, not personal development or direct technical expertise. Please therefore take these suggestions with caution and verify them independently. 1. **For the search results list**: Instead of a completely custom-drawn component, have you considered migrating to **wxDataViewCtrl**? It connects natively with the operating system's accessibility APIs (VoiceOver, Narrator, Orca). Regarding your concern about losing the custom colors of the lines, **wxDataViewCtrl** actually supports cell attributes (wxDataViewItemAttr) and custom rendering engines, which allows you to customize the text and background color while remaining fully accessible. 2. **For the Preferences sidebar**: Your idea of switching to an arborescent-style component is excellent. However, **I do not recommend wxTreeCtrl** because it is an old component that has accessibility problems similar to wxListCtrl on Linux and macOS.I instead recommend **wxDataViewCtrl configured in tree mode**. This gives you: - ✅ Tree expansion/collapse arrows natively - ✅ Perfect native accessibility on macOS (VoiceOver), Windows (Narrator), and Linux (Orca) - ✅ Custom colors via wxDataViewItemAttr without breaking accessibility - ✅ Universal solution that applies to all platforms **Important prerequisite**: use wxWidgets **≥ 3.2.1** (accessibility bugs have been fixed since this version). Thank you again for your hard work on this project! I am available to help test accessibility after implementation if you wish.

[nickinesio]

Thank you again for your work on accessibility. I also wanted to share another suggestion: **keyboard shortcuts for navigating between tabs**. Twenty years ago, I used eMule on Windows XP, and if my memory is correct, there were keyboard shortcuts to switch screens: for example, to go to Search we pressed **Alt+S**, and to go to Transfers we pressed **Alt+T**. This greatly facilitated navigation between each tab. On macOS, this is entirely feasible, but you need to go into the **toolbar** (not the menu bar) and add keyboard shortcuts. I interact with the toolbar via VoiceOver, so this could be a practical option to implement. Adding keyboard navigation would significantly improve accessibility for users who rely on screen readers or cannot use a mouse easily. Très cordialement Nicolas REYES

[got3nks]

Thanks — the suggestions are sound on the technical merits.

Quick status against the three points:

1. wxDataViewCtrl for the Preferences sidebar in tree mode — matches the direction outlined above, and aMule already requires wxWidgets ≥ 3.2.0 so the prerequisite is met.

2. wxDataViewCtrl for the search results list — direction is right and wxDataViewItemAttr does cover the per-row color question. Honest caveat: the current list is fully custom-drawn (wxLC_OWNERDRAW), shares sort/column infrastructure with several sibling lists, and at large result counts needs a virtual model, so it's a real port rather than a swap.

3. Alt-letter shortcuts to switch tabs — reasonable and independent of the a11y refactor.

Thanks again.

[nickinesio]

Thank you so much for this detailed and very honest feedback! I completely understand that refactoring the search results list represents a significant amount of work due to the virtual model and shared infrastructure. The fact that you are willing to take this direction and improve cross-platform accessibility is wonderful. Adding the Alt-letter shortcuts to switch tabs is also a fantastic idea that will make keyboard navigation so much easier. Please feel free to reach out to me whenever you need someone to test your progress; I would be more than happy to help see this project move forward. Thank you again to the whole team for your dedication and hard work! Très cordialement Nicolas REYES

[danim7]

Hello,

When you say:

I am reaching out to report a critical accessibility barrier in the current version of aMule.

Do you mean it worked in a previous version of aMule?

As a workaround while you wait for a fix, have you tried amuleweb or amulecmd ? Maybe they work better with VoiceOver.

[nickinesio]

Hello, To answer your question, this is the very first time I am using aMule on macOS, so I cannot tell if it worked in previous versions. However, based on the technical analysis, it seems the search list has always been custom-drawn, which explains the accessibility barrier. Regarding the workarounds, I am not comfortable with command-line tools like amulecmd. As for amuleweb, it requires complex configuration files to set up, which is not user-friendly.I prefer to wait for the graphical interface improvements. Your colleague got3nks mentioned earlier that switching to wxDataViewCtrl and wxTreeCtrl would be the right direction to fix these issues natively on all three platforms. Thank you for your help and for looking into this! Très cordialement, Nicolas REYES