Accessible interpreters on the Mac?

Hi everyone,
I am trying to get back into the interactive fiction seen after some time away, and I’m wondering about interpreters for OS X. my particular problem is that I use Apple’s built-in Voiceover screen reader, as I am totally blind.

When I played IF previously, I was able to use Zoom, but this has a variety of issues under current versions of OS X, and is not reliable.
I gather the current consensus seems to be that Gargoyle is a good alternative. However, it’s totally unusable with speech. I would very much appreciate any thoughts on what could be done. I can certainly play games on my iPhone, but would much rather have a physical keyboard in this instance.
Thanks much for any input.

You might give SpatterLight a shot. It hasn’t been maintained in a long time though and I quit using it due to bugs. Same situation as Zoom I guess, only different bugs.

Does VoiceOver work in a terminal window? If so, then you can install Frotz the command-line interpreter, and at least get older or smaller z-code games working. I’m not sure if there is a Terminal-window-based interpreter that can run the newer Glulx games.

I keep Glulxe/GlkTerm and Glulxe/CheapGlk up to date.

Thanks for the responses… The chief attraction of Zoom was that it could read output from the game sequentially. VOiceOver Terminal support isn’t ideal, but I guess I can live with it.

Seeing as Zoom is open source, has anyone considered leading an effort to modernize it? In particular, the Treaty of Babel stuff would be a shame to waste. I don’t know how much of an effort modernizing the code would be, but in my case attempting to compile it has thus far proven unsuccessful. Alternatively, could speech support be added to Gargoyle?
Thanks much for any input.

I’ve looked at Zoom (and CocoaGlk) a tiny bit. I believe vimes has looked at it a tiny bit. I would be very happy if it got some bug fixes and modernization. But it’s a big project and I can’t spend the time that it requires.

Cool! I can’t remember why I didn’t install that in Ubuntu. I ended up just starting Gargoyle from the command line for Glulx games. Possibly I just overlooked it. I did install Frotz. Anyway I kinda preferred when I was compiling to z-code and could debug all in the command line, so I should really go with your app.

I would dearly love to play IF again without fear. I, too, am a blind player and use Mac’sVoiceOver. As it stands right now, I use Spatterlight, but it has some unacceptable bugs.

There is no graphical interpreter that I know of that is fully accessible. Spatterlight comes closest, but VO does not read status lines or in-game menus. This can make games absolutely unplayable, since essential information is sometimes contained in the menus and they either cause VO to lose track of the game text or if I’m lucky, the menu options are read but I cannot arrow around via keyboard to select any option, so in either case, it is useless.

Zoom refuses to run games at all using VO. I get an error that Cocoa GLK has crashed. The app itself is read by VO, but that doesn’t help if it won’t run games. Not to mention controls have helpful tips when you hover over buttons, but they are read as images and are therefore not useable with a keyboard.

Gargoyle does not read at all. Not even the app. All I get are the icons to Close, Minimize, etc.

It’s very frustrating to be limited in which games I can play, especially because these are text-based and should actually offer the widest selection for blind players as compared with other types of games, like board or video or physical/athletic. Currently, I’m pretty much limited to Inform or Glulx games that can be played with the full experience, but only because of IFrotz. If those games have menus, then I’m forced to play on my phone if I need to access them, which can be problematic for hint menus. I can play TADS games with Spatterlight, but as mentioned already, it’s not ideal. I feel like I’m encountering problems that really should not exist in this day and age.

Just adding my voice to the need for at least one accessible Mac interpreter because right now, there isn’t one that can be counted on to play every game smoothly.

Sorry things have fallen so far. In my opinion the problem is that blind players of text games are a niche within a niche, and platforms have been changing so much lately that even a single layer of niche has trouble keeping up. (For example, I’m not blind but I too am frustrated at the current landscape of interpreters because I have a beautiful Android tablet which is almost useless for IF despite being a near-perfect technology for it, hardware-wise. I really regret the overwhelming focus on iOS among IF mobile tool developers, it was a bad strategy that needs to be abandoned. iOS is not the mobile world and it never will be the mobile world because it’s not an open space – it is a cultural space entirely controlled by one dictatorial company. It’s AOL. Imagine if, in the 90s, this community had released a bunch of premier IF tools that only worked in AOL – this is kind of where we are today in the mobile space.)

Anyway it’s been four or five years now of a very poorly served mobile space when it comes to IF. If the IF dev community is not really capable of serving Android very well, which is actually a huge userbase, it’s no surprise that blind players are increasingly stranded far out to sea.

I expect that as the new hardware space starts to fill in, things will also get better again for accessibility on all the platforms, due to devs just having more time available. RIght now it seems like everything is moving faster than everyone can handle. I have not seen the field of interpreters in such a poor state compared to the hardware possessed by the end users, since the early 90s. (At least not in my memory.)

EDIT: Another significant trend is that more programmers these days are trying to do things in a cross-platform way (code once, port multiple times) which means they don’t want to use, or aren’t aware of how to enable, technologies specific only to one platform, like VoiceOver, which depends upon Mac-style text handling. I’m guessing Gargoyle doesn’t use any of the standard Mac text handling routines, preferring to do things in a more cross-platform way. It’s complicated but in the end it comes down to the same issue: just not enough developer time to serve everybody, even before accessibility is taken into account.

Honestly this is because IF development is just very sparse, overall, total. Compared to the general programming world.

Zoom for Mac should be the answer here. Zoom for Mac has bugs which have prevented any serious use of it for the past couple of years. If it gets fixed, that will be the answer again, but I don’t know when that will be and I don’t have spare resources to pitch in. Spatterlight is out of date and Mac Gargoyle doesn’t handle voiceover. We have a small number of points of failure here – that’s a real problem.

You say that iOS has “overwhelming focus” when there are two Z-code interpreters available for it. Three if you count Activision’s proprietary one. That’s not overwhelming.

Good point. I may be forced to write my own Android interpreter in the endgame for my comic/text thing that ultimately is a form of graphic adventure. There is one particular episode in the works that I would really like to release as a mobile game, and it’s not going to be iOS. When I do get there, I will try to design for the most general case possible so the interpreter can help others. But I doubt I will be at that stage for a year or two yet – if I ever even get that far.

Isn’t it fair to say that the existence of a great cross-platform tool like Gargoyle has substantially reduced interest in improving Zoom and Spatterlight? I remember the days when Mac users used to always freak out about cross-platform tools, in the fear that apps that did things ‘the Mac way’ would wither due to lack of interest, and die. Seems like this is a perfect example. No offence to Dannii as it’s certainly not his fault but maybe it is the very existence of Gargoyle that is killing interest in maintaining more Mac-specific tools. I know the last time somebody complained about Zoom, I responded, ‘Just use Gargoyle.’

Okay fair enough but since I can’t even find one Android interpreter that will run a Glulx game, forgive me for perceiving the iOS situation as an embarrassment of riches. 8)

What’s this got to do with me?

(Though I do hope we can get another high quality cross platform interpreter soon, with screen reader support. Maybe through WebKit?)

Sorry man, I was under the mistaken impression I guess that you had something to do with Gargoyle development. Probably I misread one of your posts.

EDIT: This accessibility issue is going to dog this community – I wonder what the value would be of adding speech synthesis hooks directly into the next definition of the virtual machine, thus allowing an in-game command like ‘speech on’ and signalling to interpreter developers that they need to build a bridge between the virtual machine speech API and the actual OS speech synthesis APIs. Then we wouldn’t just be solving it on the Mac but on every platform with speech synthesis capability, in the long run. Also, things like menus and status lines could be handled by the system with the right info – it is unrealistic to expect general speech synthesis solutions to know what to do with those kinds of interfaces. Accessibility is important and IF has all of its own idiosyncracies and can we really rely on operating systems APIs to remain stable enough that we can take a ‘hands off’ approach and let standard text processing handle it? Isn’t the blind audience big enough that even an IF-playing subset is a formidable number of potential players? Seems worth it for the community to actually take ownership of this, though it is just a suggestion since I wouldn’t be the one who has to do all the work.

It wouldn’t make much sense to somehow enable screen reader compatibility with a separate command when you could just provide the text in a screen reader friendly format in the first place. (For a sighted person it would make no difference in the program’s behavior.) I’m afraid no specification can force an interpreter to provide screen reader support anyway, other than giving strong recommendations.

Well you could signal it as an expectation, at least, that no interpreter can be called a complete implementation of the spec without functioning text-to-speech support that also covers status lines and menu interfaces – but yeah, good points.

Hi all,

I wasn’t expecting to see a lot on this topic when I came back here, but this is interesting discussion. I agree that it really doesn’t make a lot of sense to have a separate “speech on,” style command, certainly not at a game level, because many games don’t begin with a command prompt and knowing when you can type that successfully is a nontrivial exercise. Some kind of interpreter recommendation is an excellent idea, especially since all modern platforms have accessibility APIs of one form or another.

On a semi-related note, I was recently disappointed by my attempt to play “The King of Shreds and Patches,” on iOS, the only other platform to which I have access. Some up skewer bug in the code for the Glulx implementation in Frotz makes it crash fairly regularly, I have reported this. Back when Zoom worked for Mac, this was a game I never finished.

My desire for an accessible system has gotten me to the point where I almost want to try learning Objective C to fix the project myself. This is the very definition of overkill. :slight_smile:

Thanks much for the fruitful and insightful discusison.
Best,
Zack.

Hi all,

Apologies for the double post. I have done some testing with Zoom, and found some empirical information on its crashes and other issues I thought I should provide. If this ought to go in another thread in another forum, I will be happy to place it there.

  1. VoiceOver on: ZCode games seem to work properly up until the second or third move, at which point the command line refuses to accept any further input. Glulx and Tads games do not work at all, crashing reliably with a problem report dialog.

  2. VoiceOver off: ZCode games behave identically as in point 1, Glulx, Tads, etc. work as expected. When VoiceOver is turned on during one of these games, the app crashes immediately.

When I say “voiceover,” above, I refer to the Apple built in screen reader, not ZOom’s built-in speaking capabilities. The practical effect of this is that I cannot multitask when playing an IF game, and saving and restoration of games becomes difficult at best because I cannot access the file dialog without crashing the interpreter.

I hope this information is useful to someone as a first place to start looking for the problems.

Best,
Zack.