Welcome, Jeff!
I have some good news and some bad news. The good news is that playing and developing IF is absolutely something you will be able to do, if you stick with it. The bad news is that with some rare exceptions, a few interpreters and most development environments are not designed to work (well, if at all) with screen readers, so learning to use them requires learning a lot of workarounds, some of which are barely adequate and are subject to change. It can be a bit of a discouraging battle sometimes, to tell the truth, but it can be well worth it for the possibilities out there. I’ll start with playing, and then move on to development.
Playing
On the parser-based side, it’s positive. For users of the NVDA screen reader, there exists an addon that enables speech output in a dozen popular interpreters. The original developer no longer seems to be maintaining it, but I have a personal copy which I have kept updated, and which I can upload here. There is also Parchment, an online interpreter which works well with most popular Windows screenreaders. I have yet to try it on MacOS, but I see no reason why it shouldn’t work, given that it competently implements basic web accessibility standards. I highly recommend it if you want to jump right in. Many games available on IFDB have a button which allows you to play in your browser, and this is the interpreter they use.
I don’t usually play IF on my phone or on Linux, so I’m not quite aware what’s available in those spaces, but someone else might have more of a clue.
Choice-based games are a mixed bag, mostly because they run in your web browser, and are therefore subject to similar accessibility bugs as any other web page. I’ve played quite a few perfectly accessible choice-based games, and plenty more which are accessible enough. It’s well worth trying a game you like the sound of!
Developing
Most of my IF development knowledge is parser-based. There may be others here with more information on choice-based tools, but for this post, I’ll stick to what I know. I’m also writing this post with some time constraints, so I may miss a detail here or there.
In terms of learning curve, my opinion is that languages with command line compilers are the most accessible to use, so I’ll discuss that sort first. You can use your favorite text editor to write them, and a few simple commands to compile them. If you develop a workflow, you can even write scripts to compile your projects for you, no typing required.
Such languages include:
-
Dialog - which compiles for the Z-machine, and has a fully featured command line compiler and debugger
-
Inform 6 - which compiles mainly for the Z-machine, and has a documented command line interface.
Both are portable and completely accessible, the interfaces are entirely text-based. Both require a library. One is already included with Dialog, and one for Inform 6 is easily obtainable from links in the Readme found on the page above.
Next up, we have systems which are mainly interacted with through an IDE (integrated development environment), a piece of software which brings various development tools together into a single interface. It’s worth noting that these systems also usually have a command line interface, but they are often more complex, and documentation is sometimes lacking or harder to find, as it is assumed you will be using the IDE to compile and test.
These IDEs range from moderately inaccessible to practically unusable. Your level of success depends a lot on your degree of proficiency with your screen reader, as very little has been designed with screen reader access in mind.
The most accessible interface by far is the Windows IDE for Inform 7, a popular natural language system. While the interface leaves a fair bit to be desired, we are able to write, compile and release projects without any barriers, and access a few more features with some workarounds. I have written some documentation describing these processes and workarounds from the perspective of an NVDA user.
Unfortunately, the latest version of the interface breaks many of those workarounds, which also locks us out of the latest version of the language itself. The most recent version of the software which is still compatible with all of the workarounds is available for download here. We can hope the software will generally become more accessible in future. Until then, if you wish to use later versions of the Inform language, you will have to learn its suite of command line tools. If you wish to use it on MacOS, you will have to use the command line tools regardless of version, as the interface doesn’t work at all with Voiceover.
Finally, there is TADS a mature and respectable language. Its IDE, TADS Workbench, is unusable with all of the common screen readers I’ve tried, although it may still be possible to compile from the command line. I’ve been told you can at least create the project directory structure with Workbench, and then write and compile manually, but I haven’t personally tried that yet.
In Conclusion
I feel the need to apologize. I hate to have been so doom and gloom here. I love this place and all of the incredible stuff that happens here. The reality is that while IF is one of the most accessible gaming spaces for blind people, many of the tools are not as inclusive as the community who uses them. I didn’t want to obscure that reality, but I also wouldn’t want to drive anyone off, and I feel a strange responsibility. On a more positive note, however, there are so many amazing folks here who are dedicated to accessible experiences, learning how they can improve the accessibility of their games, and are happy to have these sorts of discussions. I encourage reading the forum, and asking more questions. While it can be a struggle sometimes, you are more than welcome here, and I for one hope you stick around. There are many opportunities, and the more of us there are, the more visible we become, and the more opportunities we create. For each other, and for people to come.