I don’t think using a bot developed for Twitch chats just to get TTS is an efficient use of resources, and it sounds pretty difficult for a visually impaired user to set up as they’d have to sign up for more things or download them, then deal with piping stuff through twitch chat interface.
That said, when I went to work on a custom client to do this (both TTY and interfacing with OGS) I was hit with some logistic issues in that the API documentation is difficult to work with. Even starting with the basics of getting a user authenticated, the information is just incorrect.
Examples: " The OGS OAuth2 system uses password-based authentication but it does not work with a user’s traditional password. You will need to direct the user to generate an Application Specific Password" – False information, a path leading nowhere. If we do searches people seem to think sending the users password directly works (hope you’re encrypting it… at least use https in requests, and good luck getting users to trust 3rd party tools to not store their passwords)
But assuming you know that the password will work, the user will trust your application and you’re encrypting their data the resource listed to request an auth token is “http://online-go.com/oauth2/access_token” (or better than listed would be “httpS://online-go.com/oauth2/access_token”) – which does not exist on the server, or at least responds as if it does not exist. Whether or not you’re trying to use http or https.
Clearly I’ll need to delve the github repo to figure out the API but the docs so far have actually caused me to lose hours of time by referencing them which is not encouraging. Actually it’s even notable that both the documentation AND the browsable REST request at “https://online-go.com/api/” show the same resource that doesn’t appear to exist.
EDIT: Actually, they are not the same resource. One is /access_token (from docs) and the other is /token (from https://online-go.com/api/), but both do report 404 not found.