bug: neu accessibility bugs

[optimatrix0]

Bug description

Accessibility Issues Report (Summary Included)

Summary

This report covers three accessibility issues I found, along with one small accessibility improvement suggestion.

• The "Install automatically after patch completion" option does not expose its on/off state to screen readers.
• Navigation inside expanded patch sources causes the page to scroll instead of moving accessibility focus.
• During patching in Simple Mode, the screen reader becomes unresponsive on low-end devices (Moto G24 and Moto G35), while it works correctly on the Moto G75.
• Suggestion: add screen reader actions to reorder apps on the home screen.

Issue 1 – "Install automatically after patch completion" state is not exposed

In Advanced Settings, the "Install automatically after patch completion" option does not announce its current state to screen readers.

When navigating to this control, there is no indication whether it is enabled or disabled, making it difficult to use the feature accessibly.

Issue 2 – Accessibility navigation inside patch sources

After expanding a patch source (for example, Official Package), navigating forward with a screen reader should move the accessibility focus to the next elements.

Instead, the page scrolls, making it difficult to reach the following controls using accessibility navigation.

Issue 3 – Screen reader becomes unresponsive during patching in Simple Mode

When running a patch using Simple Mode, the interface is blocked until the operation finishes.

On lower-end devices such as the Moto G24 and Moto G35, the screen reader becomes unresponsive during the patching process, making it impossible to follow what is happening.

On the Moto G75, however, this issue does not occur. The interface remains responsive and the screen reader continues working normally throughout the patching process.

Because of this difference, I believe the issue is worth investigating, as it may be related to device performance or to how Simple Mode handles the patching process.

Suggestion – Accessibility actions for app reordering

Now that the home screen supports reordering applications, it would be helpful to expose accessibility actions such as Move forward and Move backward for screen reader users.

I understand there may be technical limitations, so this is only a suggestion.

Thank you again for all the work on this project. Accessibility has improved significantly over the last few releases, and I'm happy to continue contributing by reporting issues and sharing feedback.

Version of Morphe (Manager) and the app you are patching

All

Morphe logs

N/a

Acknowledgements

• I have checked all open and closed bug reports and this is not a duplicate.
• I have chosen an appropriate title.
• All requested information has been provided properly.
• The bug only affects using Morphe (Manager)

[MarcaDian]

Please test this to see if everything is fixed
https://github.com/MorpheApp/morphe-manager/actions/runs/28447655876/artifacts/7982022096

[optimatrix0]

The only thing I haven't tested yet is the simple mode execution, because I don't have the required device with me at the moment. The other points I did test, and they're working — especially the package list scrolling, which is now behaving exactly as it should. The automatic installation button also displays its state correctly.

The sorting feature left me a little confused, though. When I opened the home screen, I tried moving Reddit down so it would be the third app on the list, but it didn't work using the screen reader's direct actions. So I long-pressed the app, navigated left and right until the last element (settings, search, sources, other apps), and then "reorder list" appeared with the screen reader. When I tapped it, I was able to go to Reddit, navigate by actions, and the "move down" option showed up — and then it worked without any issues. Maybe that wasn't the intended behavior, but it's working for me. It would be even better if it were included by default in the direct actions, but it works. That's just a small adjustment that can depend on your time.

Other than that, I'll owe you this one, but feel free to mark it as resolved. Based on what you said, if you handled it the way you described, you have my full trust.

[MarcaDian]

I took your wishes into account, but it needs to be tested so that I can add it to the release
https://github.com/MorpheApp/morphe-manager/actions/runs/28464304648/artifacts/7989072160

[optimatrix0]

I tested your latest build and yes, the actions are working correctly now—exactly what every screen reader user expects. Thank you! I actually added it to a local HTTP server I have, shared it with another phone, and installed it.

However, when I turned off advanced mode and switched to simple mode to test the function you implemented, I clicked "patch" to update YouTube, and the only thing the screen reader read was the "Cancel" button. I'm sorry, but it seems this fix didn't work for this specific scenario. The only thing the screen reader detects is that cancel button.

I tested this on both my Moto G24 and Moto G75, and both replicated the exact same behavior. Unfortunately, this means the patching interface has become completely inaccessible for now. It's a good thing you asked me to test it! These things happen.

Unfortunately, I can't send you the logs since I'm not an expert in that area, but this is a real-world scenario and highly reproducible on your end. You should be able to verify this quite easily with a screen reader on your side. Thanks again!

[optimatrix0]

Since all the other features you developed have already been tested, the three main ones that are working can be safely implemented without any major issues. It's just a matter of us testing and figuring out this specific issue with the Patcher screen.

As it stands, it becomes completely unresponsive when using a screen reader on entry-level devices. Meanwhile, in the other scenario, it becomes completely inaccessible even on mid-range phones.

[optimatrix0]

Ideally, the screen reader should be able to read all elements on the screen, just like it currently does in the pre-release and stable versions where everything is being read correctly. It seems that what actually freezes the screen reader are just the very heavy animations, especially on budget devices.

From a user's perspective, implementing some form of screen reader detection within the app to automatically disable animations when an accessibility service is active on the Patcher screen could potentially solve this issue.

Whatever else I can do to help, please feel free to send me the instructions. I'm more than happy to test it out and help you resolve these bugs. I'm fully committed to collaborating and will do whatever I can to assist!

[optimatrix0]

Just to be clear and concise: your fix actually worked to prevent the screen reader from freezing the interface on the Moto G24! The app remained responsive, which is great.

However, the side effect is that the screen reader now only detects the "Cancel" button. This proves that removing the real-time animation (the spinning circle) solves the freezing problem completely.

If we can just replace that spinning animation with static text updates when a screen reader is active, it will be perfect: no freezing, and full accessibility to the text.

[MarcaDian]

Try this
https://github.com/MorpheApp/morphe-manager/actions/runs/28466856196/artifacts/7990105546

[optimatrix0]

AMAZING NEWS! I just downloaded the new build on my Moto G24 and it's working perfectly. It's fluidinho, fluidinho (perfectly smooth)!

Everything is highly responsive, and the Patcher process is running flawlessly. I'm truly grateful for this. This task can now be marked as officially closed and completed! Thank you again.

[MarcaDian]

That's great. So it'll be in the dev version tomorrow.