Z-machine/glulx, headers and screen readers?

Recently I added support to You Won’t Get Her Back to give the user an option to have the current board status printed in the header. It required a lot of pipes and minus signs and periods and plusses.

This would be a mess for a screen reader in the game text, and it’s serious enough that I might want to give the player a way to disable even possibly changing the header.

So my questions are – when a z-machine interpreter interacts with screen readers, does the user get the headers every turn? Can they shut it off?

This may be more a general design issue, but I realized I didn’t know when and how headers appeared or got printed or re-printed, and it would be useful to do this. It might save processing time for standard interpreters, too.



Does header = status line?

Yes, that’s what the question is about.

(I expect the answer depends on what interpreter you’re using, but I don’t have a table on hand of what to expect.)

Terp + reader tech, in my very limited experience.

I make shallow passthroughs with my story file because I sometimes use special characters. I also do so when writing accessible feelie documentation. This is only for Windows tech—I can’t speak to other platforms. People who use this technology day-to-day will have better answers, I am sure, these are just my experiences with trying to make accessible content.

  • WinGlulxe + Windows Narrator: so far as I can tell, it never reads the status line, since it is a bit like printing your old Zork transcript on a tractor feed printer. Every line is read as it is completed.
  • Lectrote with Narrator (default settings): I was able to select the status line and get a read, but for me it only reads when selected.
  • Lectrote with JAWS and NVDA (the big two windows reader apps) I believe by default only read the status line when selected for reading. It’s a different approach vs the WinGlulxe/narrator setup.

I haven’t had the best luck with Gargoyle. Perhaps there is something in the *.ini file

JAWS supports very granular configuration, so I am not sure what role that would play.


The way Gargoyle is implemented makes it effectively impossible to be used with screen readers: very roughly, it’s equivalent to a picture of text rather than the text itself.

Gargoyle does include built-in text-to-speech support by setting speak 1 in the configuration file. This uses the native TTS engine on various platforms. It should sound pretty good on Mac and Windows and generally like garbage on Unix platforms, at least with freely-available backends for speech-dispatcher.

Other interpreters are probably better to use for this, since you’ll be able to use your own screen reader software that you’ve likely configured exactly the way you want.



Apologies for not mentioning Parchment sooner. It seems to work well for a non power-user like me. It doesn’t repeat status lines out of the box with Narrator, JAWS, or NVDA

1 Like

The Mac-only Spatterlight has a shortcut to read the status bar (Alt + Cmd + Backspace), and you can move the VoiceOver cursor to the status bar, just like to any other text field, but it won’t be read automatically during normal play.

EDIT: Yazmin uses the same keyboard shortcut. I can’t remember which one had it first.


One more thing: I asked a friend.

Yes, in my experience screen readers do not read the status line automatically. Example: I played Infocom’s BorderZone several months ago using the text-to-speech function built into Frotz. It is beneficial for me that the status line is not automatically spoken. Chapter 1 (“The Train”) is a timed chapter, so hearing the time frequently would have driven me crazy!

I have very limited experience using JAWS and NVDA screen readers as my “voice” for a game I played which uses the Parchment interpreter. Same situation, except that in Parchment I have to manually read room descriptions. Consequently, I would typically skip reading the status line entirely. Feel free to forward to your questioner my response above.

1 Like