Designing for Accessibility (Happy Disability Pride Month!)

You definitely should! If there’s a best practice, we should try to work towards it as a community. & maybe document it someplace. Not signing you up for that! I’m just recognizing in general that “it’s one of many possibilities somewhere in this decade-long conversation” is not a guideline. So, how can we find the best thing and make it easy for people to discover and replicate?

I guess there’s always the question of “what is the map for?” In the old days, maps were part of a hinting system and were very spoiler-y. There’s also automapping, which is a way to keep track of progress and exploration, and then there’s what I guess I would call tactical awareness, which a map in your game would provide.

Yeah, I like that.


Then you gotta supply responses when you command other characters that question. Like

"I dunno! You live here and I'm just trying to investigate a murder here!"

Thanks, Max, for pointing a topic in NPC talking whose has sense in my WIP and totally escaped my mind !

Joey: concur with Amanda and Drew, I suggest that the map player mode can be converted into a contrib library, with the addition of checking for “visited room” status, because can be an useful tool, not only for blind people, but also for Imps.

Best regards from Italy,
dott. Piergiorgio.


Also, hello! It’s nice to return to so many replies. I think that I’ll try start updating the topic/top post/OP with things that have been brought up. I probably won’t be able to get to that for a while, though.

Or how terps work with them. I do not believe that all interpreters support screen reader tech, though I don’t think anyone has performed a survey.

Of course. Thanks for reminding me.

I’ll check it out! I have the demo of JAWS that I use to check special characters (I use NVDA, too), but I should take a look at ZoomText.


I guess you would just have to make it clear that this is a meta command (if that’s the right term) like HELP or HINT. Or you could simply train the game to pick up on keywords like WHERE and LIVING. I mean, a player with any experience wouldn’t say BOB, I NEED A HINT.


In TADS 3 (or maybe just the Adv3Lite library? Not sure…) There’s a GO TO (room) command. The idea is you say something like “GO TO HANGAR”, and the game would find the path there, and then you’d use the CONTINUE command for each step of the way.

Now, while I’m sure plenty of people would find this handy, the automated stepping through the path can have some odd problems, where the pathfinder finds unexpected glitches in your map (for example, locked doors can be silly sometimes).

I feel like my ideal method would be your WHERE IS command, where it gives you directions, and you follow them yourself. Additionally, automatic stepping (admittedly) causes me to zone out, and I find that I’m no closer to learning the map once I arrived at my destination. If I had to explicitly follow directions given to me, I’d be more likely to learn the map as a bonus benefit.

I remember seeing a project to revamp pathfinding for Inform, which could be leveraged as part of the WHERE IS command. It might be handy to allow rooms to disqualify themselves from pathfinding, to prevent spoilers being revealed after a locked room gets its name printed in the directions.

This is another genius approach to the problem, as well. Have an NPC or consultable object that provides author-written directions to various rooms. This sounds exhaustive, but it doesn’t have to be. Y’know how if you ask someone over the phone where a room is in a large building? And they’re usually like:

Okay, you want to find your way to the computer lab. From there keep going north down the hall. When you get to the T-intersection, turn right, and it will be the fourth door on the right.

The reference locations would hopefully be nearby and easier to locate, and from there, you just follow the directions to go through the much longer path.


… Which means implementing right and left, or attaching them to doors.

1 Like

Yeah. I always regret zooming somewhere if that’s an option. I don’t get a sense of the map at all that way, and it doesn’t feel real, of course.


You’d use compass directions in an actual game. I was referring to when I’ve had phone calls like this in real life. :grin:


It’s very clever for visited rooms. Hell, I would use that and I’m not blind.

It could also work as a homing device of sorts. Type > LOCATE LIVING ROOM and each room you visit could provide an extra sentence describing the direction you need to travel until you finally enter the living room. If you decide to not go to the living room, you could type > IGNORE LIVING ROOM or some such thing.

Just thinking out loud mostly.


What about a special character for meta things, like a #?


1 Like

Which means typing it in. This could be another problem (I was suddenly thinking if it is hard to input keys like that when using a screen reader).

1 Like

Excellent point. I’d better close my eyes and start playing some parser games to find out. :slight_smile:


One other idea is to make the meta command feel less meta…


And in the spirit of the homing signal idea…



well, depends on your familiarity with the keyboard (often I must watch meowies around looking for attention-giving mischief when at keyboard…)

Best regards from Italy,
dott. Piergiorgio.


I know people are already talking about this in another thread, but I’d also like to raise the point that accessibility doesn’t just apply to blindness or deafness. it also applies to things like:

  • accessing from mobile (for ex: the mobile issue with parser interpreters and sometimes simply not being able to open a gblorb package on your phone, mouseovers and hovers in twine games)
  • accessing without internet (can you download it? do you have/need an interpreter? do you know how to use it?)
  • the learning curve of how interactive fiction games (esp parsers) function and can be interacted with (see: the TALP jam’s target)
  • colorblindness
  • free vs paid games (more relevant for choice-based here, I suppose)
  • accessible translation of “natural languages” like inform 7 for devs who don’t speak english

if this is out of scope for this conversation, then fine. I just wanted to bring it up


It isn’t. I think people are bringing up things they’ve dealt with personally, but the topics you mention (and others, I’m sure) are welcome here.

EDIT: since my knowledge of the world is limited, I think it would be helpful if posters support conversations that they would like to have.


For accessibility guidance, I like Game Accessibility Guidelines, even though a fair few of these aren’t exactly pressing issues in Interactive Fiction (it’s a rare IF that has a haptic mode, for example).

I am writing a visual novel, which brings both extra options and extra requirements to the table. At the moment, the coded-in accessibility elements are:

  • translations: 7 finished, several more in progress (for the demo; full game’s not available in 1 language yet)
  • text: 3 sizes, 8 colours, 4 fonts (including an easy-read one for language learners and 2 common “plain” fonts), no use of italics or bold, maximum 3 lines per screen, auto-progression option, all text self-voiceable
  • textbox background: 8 colours, plain background.
  • image backgrounds: While no dedicated alt text is used, every background has at least some of its relevant features described in text.
  • no animation on anything that needs to be selected
  • only one action at a time is required (e.g. no drag/drop)
  • music: volume, pan on/off, on/off (all or by instrument)
  • voice: text-to-speech on by default (with volume control), using the operating system set-up as modified by the player for self-voicing. Option for clipboard text-to-speech (which allows the text to be put into the clipboard, at which point some text-to-speech readers can work with the text that otherwise couldn’t) or to turn it off (useful if a text-to-speech reader doesn’t need such help to read the text, or you don’t want voice).
  • changing title screen to reflect current objects on the last save played
  • “continue” option
  • checking that mobile elements will be large enough (even though the only mobile-compatible version I currently have is a web version in testing)
  • support for windowed mode
  • important elements of character state displayed prominently in text-read text at every decision
  • almost-full rollback and roll-forward (it’s impossible to go to the very first screen for technical reasons, but otherwise it is total)
  • instructions for how to interact with the game on the very first screen
  • full tutorial option, with the ability to end it at various points, as well as a story section, reachable at the start but also completely skippable
  • a fast(er) travel system
  • option to go back to the point where the last mistake was, in cases that would otherwise end the game
  • support for keyboard, mouse and a variety of other controllers, although a few accessibility options are keyboard-only and I am experimenting with a gameplay addition that, if implemented, will make some bonus actions keyboard-only
  • unlimited save facility with thumbnails
  • autosave on exiting the game
  • text file for the “About” file
  • accessibility option list in the “About” file and (if I recall rightly) the listing
  • testers with a variety of disabilities and levels of gaming experience

Still trying to make work or in progress, in no particular order:

  • Cyrillic text (2 translations are waiting on this)
  • full image alt-texts
  • music captioning
  • sound cues (and captioning)
  • stereo/mono toggle
  • a macro system
  • maps for travel in the game
  • some method to reduce the sharpness of colour contrast during scene transitions
  • NVDA compatibility
  • the ability to turn some non-critical content on or off
  • the ability to change control mapping
  • option for a cooldown period between inputs
  • objectives system

Would like to have but not sure how to make work:

  • an installer

This is a very impressive list of features! IIRC, you use Ren’Py. Does it support any of these features out of the box, or does it require a lot of customization on your part? I wonder which platforms/toolsets are better suited to implementing recommended accessibility features.

For instance, since Wade and I talked a little about it above: the IFTF report recommends that all “visible objects and exits” be displayed at all times by default (it can be turned off). From an Inform 7 perspective, that’s pretty complicated (EDIT: and I’m not sure screen readers would handle it well). Twine, on the other hand, is good at this kind of visualization. I’ve seen Ren’Py games do this kind of thing, too, but I don’t know how easy it is.

The base capabilities and strengths of different development systems vary so much.

1 Like

Warning! Long reply alert!

Short answer: Ren’Py has quite a few features out of the box, some that are trivial to add, some that require a bit of programming (but nothing likely to daunt someone used to, say, Inform) and some that require substantial programming. However, none of the things I’ve described, as far as I know, require quite as much programming as some Ren’Py authors employ in order to make their visual novels graphically compelling (that, to my less experienced eye, is next door to magic).

To answer some of your latter points first, Ren’Py by default displays every choice, thus every exit. It’s possible to hide/reveal choices that can’t currently be taken, hide choices until some trigger is met, prioritise which choices are seen and hide the rest or do other tricks to obfuscate options. However, all of these are more complicated than the accessible choice of simply showing every option. (In theory it’s even possible to use a menu item to launch a parser or psuedo-parser, although that would be hilariously complicated to program.)

Objects are more difficult, largely because Ren’Py doesn’t assume any objects will be involved by default. These have to be programmed and described individually. If one wants those objects to be visible, one will need an inventory. (Budacanta has a “rucksack” facility for this; it’s straightforward enough to program the container. Rather more difficult is programming when items will be visible. Even more so if one would like to be able to use items manually in the inventory. The latter two elements don’t get much help from Ren’Py, although it is possible with canny use of the state-tracking). Making it visible at all times would require two separate user interface changes (one for the choice screens and another one for the rest), may not be compatible with self-voicing or screen-readers, and would cause user interface problems for sighted players in the typical mid-game inventory situation.

Ren’Py’s self-voicing will handle all visible text, although screen-readers’ ability to do likewise may vary (I’ve not figured out how to get NVDI to work with it).

Ren’Py does have some features out of the box that are helpful to accessibility. For example, the unlimited saves and auto-saves are built into the engine. It is able to do things like multiple controllers and self-voicing provided you don’t do anything that messes it up (Ren’Py allows a lot of flexibility for advanced users but one has to be careful not to lose benefits that are naturally there if one had just kept it simple).

Ren’Py has controller instructions out of the box, but not remapping, how-to instructions or tutorials. I’m still working on the remapping (at the moment, control profiles are the main delay), instructions on the first screen were as easy to program as any other choice text and the biggest issue with the tutorials was remembering to give the player the option to stop it and just play the game every so often :smiley:

Translations aren’t there straight out of the box, but there is a mechanism that simplifies a lot of the necessary effort. Provided, of course, that your translators follow your instructions. Remembering to describe all backgrounds’ essential features gets easier with practise. Things like the “continue” option on the start menu and “return to before the mistake” option have to be programmed in, using Ren’Py’s ability to keep state information to help with the background book-keeping.

Rollback exists but defaults to around a dozen screens, albeit changing that requires only a number and a mental note that for an intricate, large game (think tens of thousands of screens, possible if there’s either a very long linear narrative or multiple hard-as-nails puzzles with no external game length restrictions), the novel may stop working on some slower computers due to the buffer size. (Depending on Ren’Py version, it’s possible to target computers running Windows 98, Max OSX 10.3 or - with some jiggery-pokery on the part of the player - original iPads and the Android devices of 15 years ago). There’s no tradition of writing additional files for Ren’Py games, so the “about” text file is something I created on my own initiative.

Areas where Ren’Py struggles (especially compared to parser interpreters) include text and background flexibility (every additional option has to be programmed manually; the defaults are accessible but boring enough that any player familiar with the engine will notice and wonder why the default was kept). Visual novels also tend to have lots of animation in the sprites and Ren’Py doesn’t build in any sort of “off” switch for this. (Budacanta currently gets round this by having no sprites to animate; some other Ren’Py novels program a switch in the game menu that allows animations to be turned off and/or slowed down).

Accessible status bars are very difficult to do in Ren’Py, it turns out. While lots of people appear able to do graphical GUIs, getting graphical status bars to work properly with screen readers turns out to be complex, especially if (like Budacanta) there are plot reasons for it not to be constantly available. Hence why I have the inelegant but thematic and accessible method of incorporating them into the choice menu, omitting information that definitely isn’t relevant to the player for that choice menu.

The most challenging one so far has been the music off by instrument. In fact, I only got the idea it was possible because I happened to see some code Alaric on a Ren’Py development Discord server. The original intention was to block insect and spider sounds in Alaric’s game. I asked permission to use it for music control (since my game still hasn’t got any sound), he agreed and I ended up splitting my music into different instruments to make the concept possible. Obviously, once I have sounds, those are going to be blockable by sound type too, and I can see how to extend the concept to allowing users to select types of written content they’d rather not see. I think it is worth it because it gives a way for people concerned about phobias, anxiety or stress ways to engage with the IF that aren’t limited to “play something else”. I like the idea of modestly extending what “accessible” can mean in IF.