I have a few questions for all of our wonderful screen reader players in the community, particularly those who also happen to play TADS2 and TADS3 games in their interpreter of choice.
Question One: What interpreter do you use?
Question Two: Does screen reading functionality work from the interpreter itself, or do you have a preferred screen reader that can read the text of the interpreter?
Question Three: How do your screen readers handle the banner of a game? Does it read off the banner every single time the prompt text changes? Or do you have to intentionally read from the banner at will?
Question Four: Is there a consistent way that screen readers handle additions to the output? Do screen readers reliably tell you only the new text that appears, or do some screen readers re-read the entire output, with old stuff included? Do you have to navigate paragraph-by-paragraph, and figure out what was newly-added?
Question Five: Some TADS 3 games allow the player to click on a bit of text in the output to perform an action, much like a hyperlink on a webpage. Do any of your screen-reader-accessible interpreters work with this at all? If so, how difficult is it to use these clickable bits of text? Do you often prefer to just type in your command at all times, or do these clickable parts provide a handy alternative?
Question Six: Are there any general annoyances that seem to happen a lot in TADS 3 games, which creates obstacles for screen readers?
Mostly asking these questions to adjust how I write games in the future. I’m very thankful for any feedback people can give!
EDIT: Some of these I could figure out by installing a screen reader and running some tests, but this is more asking about the experience from someone who has spent extensive time using them.
I play almost all my IF in Spatterlight, a multi-platform interpreter for Mac OS that handles everything from TADS and Inform to Level9 and Magnetic Scrolls.
All Spatterlight text is read by Voiceover, Apple’s native screenreader. Somebody correct me if this is inaccurate, but I don’t think self-voicing interpreters are very common since they would need to include their own built-in speech engines that work separately from whichever system-wide screenreader is being used. Gargoyle is the only one I can think of that does this, but I was never able to get its text-to-speech feature turned on so unfortunately I can’t provide any insights in to how such a setup would work.
Does the “banner” refer to the game’s main window where parser input and output take place? If so, then all changes to text here are read automatically: e.g. after a new command is entered.
Spatterlight is very good about reading just the new text in a game’s output log.
I generally prefer to type my commands directly in to the parser because it increases my sense of interactivity. However, I can confirm that the simulated hyperlinks do work in Spatterlight–I actually helped test that feature :).
I’ve definitely encountered a few pain points throughout my IF experience, although I don’t think any of them are necessarily TADS-specific. For example, puzzles that require a player to refer to ASCII graphics are essentially unsolvable because ASCII art is incompatible with screenreaders. Flipping that coin over, there’s the usage of real graphics, although that’s only really a problem when they’re integral to gameplay and aren’t accompanied by text captions. 1893: A World’s Fair Mystery (TADS 2) was filled with photos but they were primarily included for esthetics and didn’t really affect my ability to play.
By “banner” I mean the little bit of text at the top of the screen that tells you what room you’re in, what your score is, and how many turns have been taken so far. (At least this is the default functionality of the banner. Some games track other stats here, and I remember hearing that banners do weird things with screen readers, so I’ve avoided making them a necessary thing
in my games so far).
Same, honestly. However, there have been situations where the actual command would be really tedious to cooperate with the parser, so I’ve occasionally offered clickable alternatives. This is mostly for computer consoles or panels that have lots of buttons.
I’d rather the player be able to click on the button in the text, than type in “PRESS NAVIGATION PANEL INCREASE THRUST BUTTON”.
I could also add new commands for a lot of this, but there are times where it would start to really confuse the parser, and there’s a whole lot of debugging and planning involved that I would only implement after the proof of concept works.
Thanks for the banner clarification, I’ve just been calling it the status window. Yes, that needs to be checked manually, either by actually navigating to it or via a keyboard shortcut. Neither method poses much of an inconvenience and I’ve personally never encountered problems with it in any of the games I’ve played.