@larsmb @mpldr But what I’m saying is, could they not post it on the third-party source, and then, at install time, prompt the user to check a box if they are okay with, require, or otherwise want to install the specific component from the specific third-party source? Like certain Linux distributions do with non-free applications and firmware. See debian/ubuntu/mint installers. I'd say just "not caring" as they are doing currently, is malicious. Everything they've said at the moment is passing the torch onto someone else. Someone needs to make an engine. Someone needs to update a component. Someone needs to configure it. They are accepting absolutely none of the responsibilities themselves.

@fireborn @larsmb @mpldr I think we've done a fairly good job of explaining the reasoning behind the way things currently are. It's very unfortunate that you've taken that and decided to write this article which misrepresents our stance and paints the project as cruel or bigoted. We do care about accessibility. We have a section on our website discussing the topic dating back a very long time. We have threads discussing accessibility topics dating back years (see https://xcancel.com/GrapheneOS/status/1596245397596692480#m as one example of that).

Claiming that we do not care about accessibility isn't just inaccurate, it's personally deeply saddening to me. You don't have to care about my feelings, of course, but I do feel that I have to express that.

You're claiming that GrapheneOS is passing the torch to others rather than assuming responsibility for this ourselves. Other than the fact that we've had endless discussions on how to tackle this internally, which of course you cannot know, I would like to posit this question:

Isn't that what open source is about?

GrapheneOS is a project providing privacy and security to hundreds of thousands of people around the world. Doing that requires constant maintenance and work to keep everything up to date and secure. Despite that, we take on as much work as we can muster. On this particular topic, isn't it reasonable for us to want someone to provide something we can use? There appear to be engines which are compatible which need to be turned into an Android app. That's something that someone could advocate for or even work on themselves to contribute to GrapheneOS. It would certainly be more helpful than being called bigoted. I understand that you might not have the necessary skillset, time, or inclination to contribute something like this, but wouldn't it be more productive to hear the project's reasoning and advocate for something being made that meets the project's needs?

Despite the end result being very unfortunate, I do understand that you probably wrote this with good intentions. It just hasn't come out that way because it misunderstands multiple parts of GrapheneOS as well as what our issue with the licensing is (as multiple people have already expanded on in their replies to your post).

I have seen replies from you that make me think that you're reasonable and that we could discuss the topic further. If I'm right about that, feel free to reach out and we can chat more.

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

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

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