Replies: 3 comments 2 replies
-
|
First of all let's get the obvious out: screen reader support. As an Ebitengine game that does all rendering via 3D render calls, there is definitely no builtin support (except maybe OCR based solutions which will be limited in quality and speed). If I had a Go API that allows speaking a text from a string, my primary idea would be speaking in-game notes and labels when touched by the player, and similarly, making every menu item that's newly selected speak its label and when changing an item, speaking the new value. Better would be integrating with some screen reader APIs so the text is spoken in the player's preferred voice and the player's language (as many pre-existing TTS solutions I could statically link to have a limited set of supported languages). Also, as this game has to conform to privacy regulations, solutions that do not need internet access are strongly preferred. Google Translate TTS is right out - not only does using it require internet access, the copyright situation of the generated audio samples also has to be checked out. Also, pre-rendering all those audio samples would easily make the game balloon into hundreds of MiB - so a local TTS engine would be strongly preferred. So - let's evaluate here which packages exist - in particular whether one can integrate with any pre-existing APIs to read out text. |
Beta Was this translation helpful? Give feedback.
-
|
Make blind able to "see" the current room? Data that we have available in AAAAXY right now:
We generally can generate sound, and maybe also rumble events for gamepads: https://pkg.go.dev/github.com/hajimehoshi/ebiten/v2#VibrateGamepadOptions (whether these work is gamepad dependent, of course). In a "fully blind mode" this probably should replace the music (where area's music tracks should only be played for a short duration when music would change, e.g. when leaving hubs). Otherwise it could be interesting if this could "supplement" the music as an option, possibly even for seeing players as a fun feature. As only few sprites are gameplay relevant, a solution could be giving them the ability to "hum" when the player gets close to them. So I guess let's ignore sprites for now. We could also add a button to "feel" in viewing direction, or maybe sweep up/down and give feedback of how close the next obstacle/wall/sprite is (kinda like echolocation). |
Beta Was this translation helpful? Give feedback.
-
|
In "blind mode", simplify or remove some sections of the game that are definitely inaccessible to those who can't see (primary one being The Wide Gap). Or use TTS to recommend the player to try something else (as this section is optional). Or make these sections easy by giving sound cues for when exactly to jump or push while holding the right button. Or compose background music with a rhythm that will make the player eventually succeed by holding right and pressing the jump and action buttons exactly in the rhythm. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Let's brainstorm what can be done to make this game - or even 2D platformers in general - more accessible to the fully or partially blind.
I am going to open subtopics for some aspects, let's see which can be defined narrowly enough that they can become Issues and then implemented.
Beta Was this translation helpful? Give feedback.
All reactions