@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.

@fireborn I can ask them. I assume that they either have their own build of GrapheneOS which includes something like eSpeak NG, or that they enlisted someone's assistance when setting the device up.

I understand that both of these options might not be feasible for some people, but they are certainly options until there's a permanent solution that works out of the box.

The article as it stands right now unfortunately gets things about GrapheneOS works incorrectly (such as the section about sandboxed Google Play which has led many people to agreeing with you based on a false premise that we include Google Play by default, which we don't).

It is really causing harm to the project and is very saddening to our team because we're being accused of being ableist or not caring about accessbility. I don't believe that this is the purpose of the article, but rather pushing for a solution and potentially getting the word out to help a reasonable solution be developed, whether by our team or a third-party contributor. I don't believe the article currently does that and I really wish we weren't put into this position of having to defend the project and ourselves by explaining we're not something that we aren't.

Unlisting it so that it can be reworded (I am happy to help provide input and make sure things are at the very least factual) seems like the best option right now, if you do not want to delete it instead.

@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.