Accessibility efforts in web-based IF?

Howdy y’all,

Has our community, or a community closely aligned with ours, put forth any effort to survey, test and (if necessary) improve the current state of browser-based IF when it comes to accessibility? I mean this in the sense of providing affordances to assist those with disabilities in playing the text games we love.

During last fall’s IFComp, I corresponded at length with a blind player who expressed disappointment that the only competition entries they could play using their computer’s braille output device were downloaded Z-code games. While they could browse websites just fine, they found that web-based IF games of any sort invariably stumped their machine, leaving the games unplayable. At the same time, I also engaged in a brief conversation or two on Twitter involving other players asking about accessibility, particularly of the Twine-based entries. I’m sorry to say that neither I nor anyone else on the “IF expert” side could offer any definitive answers.

But this isn’t just about Twine, nor is this just about vision-impaired players. Almost every new work of non-commercial IF produced today — whether parser, hypertext, or something else — is either web-exclusive, or can be played through a web-based interpreter. And that’s great, in part because there today exists a wealth of well-developed technologies, techniques, and standards to help make web-based software accessible to as wide an audience as possible. (I was, for example, very happy to hear from my interlocutor that the website worked great on their braille browser. I give full credit here to the site’s underlying Bootstrap framework, which provides a lot of accessibility magic for free.)

I do not at this time know, however, whether or how well we the creators and maintainers of IF web software have basked accessibility into our designs. This isn’t a rhetorical question — I really don’t know the answer! I’d love someone to tell me that one or more popular engines or interpreters has accessibility (or “a11y”, as the Twitterati call it) in mind. For popular web-based IF platforms not on such a list, though, I’d like to ask what we can do to start improving them in this regard.

That’s odd. Creatures Such as We should have worked just fine; lots of visually impaired users play ChoiceScript games and we’ve heard that they work.

Wade Clark has posted in his blog about his experience with making Leadlight accessible, and raising awareness of a few issues some people (i.e., me) might not otherwise have known about. … art-1.html

I’m happy to hear that about ChoiceScript!

As for this person, I don’t know at this time if they methodically tried every entry that wasn’t z-code, or if they looked at a few, had no luck, and gave up. It’s entirely possible that the two ChoiceScript entries would have worked fine.

It may be that it will be up to us who use alternate means of playing the games to let game and system creators know of any problems and offer our testing services. I’m willing to test anything for accessibility, but I might represent just a small proportion of these individuals, those who use a screen reader (and only one brand). I don’t use braille outputs.

I talked about accessibility issues in a previous thread. Maybe I’ll summarize my experiences and put them on my website. It is getting harder to play games as game creators experiment with different tools. Adding music, for example, can drown out screen readers. Relying on colored text or other text effects can be a problem. Webpages with a lot of input fields, drop-down boxes, JavaScript, or graphics can be tricky to navigate. And then some browsers are more accessible than others. I recommend anyone who uses a screen reader to use Firefox for hypertext games.


Coincidentally, I’ve recently been adding screenreader support to an unrelated web app with similar properties. It seems that adding aria-live=“assertive” property to Parchment’s main element makes it work somewhat better, at least in OS X’s Voiceover. It reads responses to commands (which it didn’t do before) but the problem is that sometimes you have to reload the page a couple of times to get it read more than just the first line from the initial output.

Could someone with other screenreaders or braille displays confirm that it works, and if it has a similar problem with the initial screen? I’ve uploaded it here: If it works for people I can make a pull request to the official version.

Note to self: Add ‘accessibility’ to requirements in quixe-channels.


This is a great improvement for Firefox and Chrome with the JAWS screen reader for Windows 7. In Internet Explorer, it reads the previous 1-3 commands, then everything (or just what’s on the screen?), then reads it again. Still, I think this is better because I can stop the reader from reading the text anytime. Maybe on the website you should recommend Firefox?

Thanks for considering this issue. I would use Parchment more (i.e., play more games online) with the update. Right now, offline interpreters are a little easier to use.


This topic has been on my mind lately. Specifically, I’ve been wondering what can be done on the library-side of things to make games work better with screenreaders. I even recently wrote to the audyssey mailing list, but I don’t think I did it correctly so I’m not sure it went through.

Questions I have: could status lines be handled better? Ideally, in screenreader mode, should they be drawn or ignored completely? Should their info be written in the main window? Do visually impaired users use BRIEF and SUPERBRIEF modes more often than the rest of us? Are there other improvements people can imagine?

Roodylib combined with my menu extension for Hugo already has support for drawing all menus as numbered lists if in the correct mode, but I’m curious what else can be done in this area.

EDIT: Oh yeah, I also was curious which offline interpreters were most popular with visually impaired users.

I would think a specific theme for accessibility would be best. Only the main story text would be displayed, with possibly a list of links that had common commands; directions, inventory, score, time, turn. I could even see writing a new command ‘status’ for all of the status line information, plus inventory and directions.

Start of Example.

This is Zork 1, The Great Underground Empire by Infocom.

You are standing in an open field west of a white house, with a boarded front door.

There is a small mailbox here.

You are in the location “West of House”. As of turn 0, your score is 0. You are empty-handed. You are in perfect health. You can be killed by a serious wound.

You are standing in an open field west of a white house, with a boarded front door.

End of Example.

David C.

I can imagine hearing “greater than” at the end of every turn can get old really fast, but sometimes the prompt contains information (“What is your name>”) so hiding it from the screen reader by default doesn’t sound like a good idea.

There’s been some discussion of accessibility on the Twine forum. Here are a few threads:

In Hugo, I don’t imagine this being much of a problem to allow for those extra cases, as authors can be directed towards using the GetInput routine (which allows for a text field) over just changing the prompt global. That’s a great thing to consider, though!

There’s an Aria feature (I can’t remember what it’s called) that would allow you to specify that the > would be read out as something else, like ‘prompt’.

I can imagine that verbosity settings are more important for people who use the tts option of interpreters. I think it would be annoying to have to listen to a full room description when just wandering around. But independent screen readers can read line-by-line and won’t read the screen automatically in offline interpreters.

I can imagine novice players who depend on a screen reader may not even know that a status bar exists. Checking a status bar requires keystrokes and can be annoying if it changes a lot. I wonder if in some cases the info can be placed in the room header, or after the room description. A separate “status” command may be a good idea when there is a lot of info.


With hypertext fiction - what would even be the optimal way of presenting things like exploratory links to users on screen readers or Braille terminals? If a link is clicked and causes some section of the text to change (Often the text of the link itself which is itself another link), how would one go about making that transition accessible?

ARIA should certainly help, but it’s been a few years since I looked at the details. Of course the more visual an effect is, even if in text, the less it will be accessible for screen readers.

I was very happy to see the interest in this topic. Thanks to all who added their thoughts to this thread.

I have been in touch with a friend who is an accessibility expert and a long-time IF supporter, talking about ways to take the accessibility-temperature of our most prominent IF creation and play platforms, and proceed to start working out improvement plans from there. (Yes, this does dovetail serendipitously with Matt Chelen’s recent list of all known platforms. No, I don’t think we must test all of them, but that’s a fine resource to have in hand.)

My next few weeks are busy with unrelated projects, but I do intend to follow up in early summer with some more concrete calls to action.