@fireborn I think that we understand more than you might initially think, especially since we've been doing work on our Talkback fork with the help of a blind GrapheneOS user for a very long time. People like that are very important for noting any regressions to accessibility (which we address before they become an issue to people in production since we realize that accessibility features breaking puts people that depend on them in a very difficult situation where they'll need help from a third-party to get things up and running again).

I want to reiterate something. This is NOT something that we don't care about, or that we're ignoring/neglecting. You can find us talking about this and us wanting to improve things in that area for a very long time. As you noted in your article, we did request direct boot support from eSpeak NG which means that GrapheneOS users or users of other OSes that don't use Google's app for this can use their devices BFU.

If we didn't care about this, don't you think we wouldn't be talking about it or taking those steps? We take time to do things right, and I fully understand that this is something that's important for people to be able to do independently and without help from a third party. If I could snap my fingers and have a workable solution that we can use in GrapheneOS, I would do it, but that doesn't exist today. Like I said, there seem to be promising leads for models we could use, but nothing that meets our requirements and is ready to use right now.

I'm glad that you're mentioning that you were frustrated by something (which perhaps wasn't understood fully, or might have seemed like us waving away a problem when that isn't what we're doing) because that means that you're willing to see that the way the blog post was written is accusatory and doesn't apply nuance or any amount of good faith towards GrapheneOS.

I'm hoping that you can take another look and take our back-and-forth as context, and maybe amend it.

At the end of the day, both sides want the same thing - I'd say that there may not even be sides in the first place.

@matchboxbananasynergy I'm considering various options. I'm not sure setting the post as draft until I can go over it is appropriate, or that it would prevent a mailing list post being sent. deleting it would also seem like a full retraction, which it isn't. This is still a problem.Could that blind user have provided instructions on how they got through any setup? I myself have plenty of experience flashing android devices. I made a flashable twrp zip to work around this issue on LOS based ROMs but not sure how much it would apply here. I still think that while a solution is being designed, there could be some way of supporting what currently exists, even if it requires a user opt in or a separate build while the tooling is made to unify the experience.

@matchboxbananasynergy what I meant by that was support for enabling that is super easy and discoverable. Enabling tts not so much. There are guides on enabling it. provided instructions. A user is hand-held through that process.

@matchboxbananasynergy If they have a build that includes espeak-ng, is this not something that GOS could provide instructions on building? Not very streamlined that's for sure, but something.

@fireborn I would need to check with them to see what they're using nowadays. They've told us that options like RHVoice and eSpeak NG aren't actually usable in practice, and they are likely using Google's app for this for their day-to-day.

As far as maintaining your own build with something like eSpeak NG goes, I don't assume that it would differ a lot from bundling any other app in a custom GrapheneOS build. If someone wanted to do that, they should be able to do it with relative ease, but at the end of the day, the solution needs to be something we can actually ship in official builds.

@matchboxbananasynergy it does, but a guide in the mean-time on how to package it yourself would go a long way towards making the process at least doable. I don't know, I personally use espeak every day and don't really plan on using anything else. Espeak can reach higher speech rates than most other things while still remaining understandable, and I don't like tts options with inflection that changes in the way that neural tts does.

@fireborn We can consider this, we do have https://grapheneos.org/build today which guides you through making your own GrapheneOS build.

@fireborn Could you elaborate on what you mean, I think I lost you there.

@matchboxbananasynergy Enable g. play services is something that is documented and discoverable. Enabling tts is less so. Could there be a modification made to settings that adds the install espeak-ng option to the text-to-speech output settings if it isn't installed?

@fireborn What would be the purpose of that? If someone has gone through the installation and setup of GrapheneOS and they want to use eSpeak NG, obtaining it wouldn't be the difficult part. Given that we have feedback that it also isn't practically usable day-to-day, and that most people end up going with Google's service for this, nudging people towards something that they'll end up needing to switch away from seems a bit counterproductive.

@matchboxbananasynergy Mostly discoverability. If you have a tech-illiterate friend/parent/who ever helping you, it's a lot easier to tell them to open settings, navigate to accessibility, and select the install and activate option or whatever the flow is, rather than get them to open an app store, maybe find the right app somehow, then install it, then go into settings and configure it. The latter option maybe would require you know what icons represent what apps. Most people generally know what a settings icon looks like.

@fireborn I can see the value in that. I think my first priority would be to collect a lot more feedback about what works for blind users. How many people use eSpeak NG, how many people use Google's app, or something else entirely.

Adding a setting to set up a specific one (such as eSpeak NG in this instance) means that we're essentially endorsing it -- which is fine is it does a good job, but so far we have conflicting feedback about that.

We could mirror it in our app store. We could do the same for Google's app, although both can be obtained from their respective app stores.

Do you believe that a video that shows the steps required to enable this would help? They would be meant as a guide for someone who is assisting the blind user to set it up. It doesn't address the root concern, but might be a stopgap in the meantime.

@matchboxbananasynergy Something else entirely would be the most common response. I really don't know who said that google's option was the best. I can demonstrate it for you if you like, but the basic idea is this. Give it more than 500 characters and your speech might be gone. or it might not. if it crashes, it might come back. or it might not.

@fireborn That's based on feedback we've received from the blind GrapheneOS user that helps us maintain our fork of Talkback.

Are you aware of other options that could be used on Android? I'm aware that for PCs etc. there must be a load of options.

@matchboxbananasynergy There's RHVoice, which you know of. It's free. Acapella and Vocalizer both exist, but are paid. Both do have a history of working with companies though, so I might be able to help you make contact if there's interest.

@fireborn Thanks, I will check those out.

@matchboxbananasynergy there's also this, but I'm super unclear on what the license is. https://poretsky.github.io/android/smartvoice/

@fireborn I looked but wasn't able to find any source code -- maybe I need to look more into it, though.

@matchboxbananasynergy i wasn't either, but I thought it was FOSS. maybe not, in which case absolutely not.