GrapheneOSIn order to provide better support for blind users, we maintain a fork of the open source TalkBack app fixing serious issues with it, modernizing it and making the builds reproducible. One of the goals of making our own Setup Wizard has also been integrating TalkBack support.
Google unfortunately doesn't publish the source code for each stable release of TalkBack as they do for Android itself. The open source release of the app lags significantly behind. It also has a bunch of missing and broken features. We plan to gradually improve this situation.
In order to use GrapheneOS, blind users need to successfully install the OS and set up the device to be usable with a screen reader. This is an area we've been thinking about and working on improving for a while. Our new Setup Wizard provides a better base for integrating this.
The first barrier to someone using GrapheneOS without sight is installing the OS. We've done what we can to make our web installer as accessible as possible (https://grapheneos.org/install/web). However, users need to interact with the device's firmware interface which the user can see.
Due to the inaccessible firmware user interface, it's difficult to perform the installation correctly and safety, particularly confirming unlocking and then confirming locking. Confirming the verified boot key matches after installing/locking would require OCR on another device.
The next issue is the Android Open Source Project no longer includes a text-to-speech app. Pico TTS used to be included in AOSP but was not what Google Mobile Services devices use. It was quite primitive, awful to use and AOSP removed it after security issues were found.
We've wanted to include a text-to-speech app and bundle a language pack to have it working out-of-the-box for a long time. We could then add a shortcut for enabling TalkBack in our new Setup Wizard to make things accessible from the start of the post-install setup process.
To provide what we need, the TTS app needs to be built into the OS, enabled and set up to work by default without configuration. It doesn't do any good if you need to connect to a network and download a language pack. It also needs to work Before First Unlock via Direct Boot.
Since it will be enabled by default, security is quite relevant. It shouldn't be a bunch of C++ code without a modern coding style, use of sanitizers, decent tests, etc. It needs to be actively developed and properly maintained. This is why Pico TTS had to be removed from AOSP.
GrapheneOS is intended to be a drop-in replacement for the Android Open Source Project usable by companies to make all kinds of products. Due to this, we avoid non-commercial usage licenses. Lots of the language packs for TTS implementations have non-commercial usage licenses.
We also avoid including GPLv3 code in the base OS since it would add restrictions on how it can be used. We do add new GPLv2 licensed code. This doesn't mean we have issues with using GPLv3 code or making forks of GPLv3 projects, we just don't bundle it within GrapheneOS itself.
Neither eSpeak NG or RHVoice meets our security expectations (piles of problematic C and C++ code) and both have licensing issues. Both were previously also missing Direct Boot support to function Before First Unlock, but we requested it from both and eSpeak NG implemented it.
There were previously no good options available. Things have changed and there are multiple open source text-to-speech implementations which could be turned into a suitable Android app and integrated into the OS. This involves significant work and we haven't gotten to this yet.
We have hundreds of planned features. We've been working on some features for months or even years. We try to focus on features which would provide the most overall benefit to our users with a focus on improving privacy, security, compatibility and usability. It's subjective.
eladnarra@GrapheneOS I think this post exemplifies a difference in approach that's causing issues.
For disabled folks, a lack of accessibility is a bug, not a missing feature. So our position is that it should be prioritized higher, not lumped into general features and improvements.
Focusing on things that provide the most benefit to users overall leaves out disabled people and accessibility by default, because we're a minority. One has to prioritize accessibility outside that subjective calculation.
@eladnarra GrapheneOS is an open source project. Blind people are 100% capable of doing software engineering and contributing to GrapheneOS. They're the people who know best about what they need and how to approach things. One of our contributors is in fact blind and helps us work on TalkBack along with helping to test it and a bunch of other things. There is a whole lot which has to be done simply to keep what we already have working. Expanding what we have requires more contributions.
@eladnarra We have a small development team and have had major setbacks due to attacks on the project, Google largely refusing to work with us and making our job harder with the Play Integrity API and recently our lead developer being forcibly conscripted to fight in a war. We're struggling just to continue the project already and are already dealing with a huge amount of hate and harassment towards us based on fabrications about us. Now we're dealing with another source of it. That's great.
@eladnarra Not clear how more attacks on us is going to improve things for our present and future blind users. This has already disrupted development, taken resources away from the ongoing port to Android 16 without the main person who did 90% of the recent ports to new Android versions, etc. Every GrapheneOS user including our blind users will be negatively impacted by the project and team being attacked with outrageously false claims about us. What should be cut to make up for it?
@eladnarra The port to Android 16 is essential to keep providing the latest privacy and security patches. Porting all of our features to Android 16 is not mandatory. Features can be dropped if needed. We're also going to need to narrow our focus and scale back what we're working on further.
The reason we have a bunch of largely unmodified AOSP sample apps is lack of resources to make a bunch of new apps meeting our standards, or to fork existing ones. The same goes for lack of translations.
@eladnarra We're successfully providing a highly private and secure OS with broad app compatibility and good stability. We're not able to do everything though. We cannot realistically make our own TTS app so we rely on there being one that's a reasonable starting point to include. Perhaps one of them is a reasonable starting point now. eSpeak NG cannot meet our requirements. Someone attacking us for not including eSpeak NG with a bunch of false claims about us is not going to accelerate this.
@eladnarra Several people have now told us about more recently created permissively licensed TTS apps which may meet our requirements.
If people put a fraction of the effort into helping us as they do harming us, things would be dramatically better as a whole.
Responding to these posts and posting about this on our timeline would have been development time. This time could have gone towards working on TTS if someone had reached out to us interested in helping us instead of hurting us.