Dark mode/light mode in IF

In the past several years, the general trend in web and software development has been in favor of light text on dark backgrounds, and it seems like this trend has extended to IF as well. (Partly this is because of Twine’s default CSS, but I’ve seen it a lot in games that have custom CSS and/or are not made in Twine, also.) It’s widely believed that dark-mode color schemes make it easier and less fatiguing to read large amounts of text, and to be the more accessible option for people with visual impairments, so this makes sense. The problem is that it’s not quite universally true.

I have astigmatism that’s not incredibly severe, but also isn’t quite fully correctable, so certain things can make text look blurry to me even if I have my glasses on, and having light text on a dark background is one of those things. (This is a pretty well-documented phenomenon – it’s not universal among people with astigmatism, but it’s common.) Going through the entries in IFComp 2020 and now Spring Thing 2021, there were a lot of instances where I couldn’t really appreciate a game’s content because trying to read the text was giving me a headache; I often have to take breaks, which makes it hard to really get immersed in a game, and if it’s a particularly long game it may mean that I don’t finish it. Of course, I could just say “clearly these games aren’t meant for me” and skip them, but (1) if I’m voting on and/or reviewing entries in a competition, I don’t like to skip a large chunk of entries, and (2) I would miss out on some very well-regarded games that way, which I’d be sad about.

So I was wondering what people’s thoughts were about how to address this (or if it even needs to be addressed at all). Personally, I would really like to see more games have the possibility of toggling between a light mode and a dark mode. (I’m going to try to put my money where my mouth is on this in future games, and if I can put together some CSS templates for this, I’ll probably share them.) But I do realize that this is additional effort for a bunch of hobbyists making games for free, and there’s also the question of how much a creator should have to compromise their artistic vision for the sake of accessibility. What do you all think?


I have no eye for design and am more than willing to believe that I am completely out of the norm on this, but I also find black text on a white background to be far easier to read than the more typical “dark” themes – just looking at the current Spring Thing, I found the color scheme made Queenlash even harder to parse, whereas the clean look of Blank Page felt like a breath of fresh air. I don’t know how much effort this would be for folks making these games, and of course I understand the aesthetic presentation is often a big part of what authors are thinking about so in some cases I can understand not wanting to give the player the choice, but put me down as someone who’d appreciate the option were it more broadly available.


I had wanted to add selectable color schemes but lacked the technical expertise. I think it would be wonderful and helpful if there was a Twine template to provide readers with choices.


It’s really easy to respect the player’s global (browser/OS) dark/light mode setting, and I think that’s a good idea. Letting the user toggle it specifically for your game is a bit harder, since it can’t be done just with HTML and CSS (as far as I’m aware), so it might not be worth it.

For Z-machine/Glulx games, interpreters can of course implement color schemes (or make the colors customizable for the player). Lectrote has two sets of light/dark modes (Light/Dark and Sepia/Slate) which look great.

It can be with the most minute amount of javascript.


/* light theme default */
body {
	background: white;
	color: black;

/* dark theme */
body.dark {
	background: black;
	color: white;

/* make links orange only on dark theme */
.dark a {
	color: orange;


// enable dark theme

// disable dark theme

// this will toggle dark theme on and off when called
function toggleDarkTheme() {
	var classes = document.body.className.split(" ");
	var index = classes.indexOf("dark");

	if (index === -1) classes.push("dark");
	else classes.slice(index, 1);

	document.body.className = classes.join(" ");

Its pretty easy to do and it works in everything from IE10 and newer. There really isn’t a good excuse not to implement it, to be honest. Other than laziness, which is my current excuse.


This is definitely not the ideal solution, but maybe an acceptable workaround. Chrome, Firefox, and Opera have an extension called Stylus that lets you alter the CSS of a specific page or address. Since most of the IF web games tend to fall in the category of Harlowe Twine, SugarCube Twine, and Quixe, you could create your own themes for each format and just apply them to the game page to make it look how you like.

Like I said, it’s not ideal, and you’re out of luck if you use Safari or Edge, but it’s at least an option.


I didn’t figure out how to do it in time for Spring Thing, but I intend to have visual scheme customisation on Budacanta.* The hints I get from what I’ve seen so far of Ren’Py suggest it can be heavily customisable if set up that way - and since that’s the case, I think it’s better to lean towards more customisation for accessibility than less. Even systems like Ren’Py, with no obvious method of detecting what colour scheme someone is using (it might be available via an advanced piece of Python code, but I barely have a toe in the water on that part of Ren’Py), have some flexibility here, and I want to use it.

Adapting the backgrounds will be trickier, although I would hope that in some cases, filtering the pre-existing backgrounds would help. Yes, this means I will end up with a large file size, but I would feel bad releasing a game where only part of the UI could be customised so as to make sense.

The other good thing is that once I figure it out, hopefully I’d be able to share the code so other people using Ren’Py don’t have to reinvent the wheel, and can instead have that accessibility with only a small amount of copying and adjusting necessary. (Simply because I hope to have Budacanta’s full version out as commerical IF does not mean I can’t give away parts of that code which would help others to create better work).

Originally, I was going to have the full game ship with vivid (high contrast colourful), cool (lower contrast colourful, which some people in my target audience prefer) and monochrome (better for use at night and for people with some visual impairments). However, you are right that it makes sense to have the inverse options available as well. (So that would be strong blue/white, muted blue/white, black/white, and the reverse of all those options).

* Specifically, I can see where the graphics would go on Ren’Py, and I think I now understand how to work the logic gates, but I still need to learn how to set the persistent variable which says which mode the user wants, how to create the slider to allow the user to choose and how to make it so users can adapt a set of graphics templates to personalise it. After all, some people don’t like blue :wink:


True, I was just trying to say that it does require JavaScript, and isn’t quite as easy as supporting the OS’s dark mode setting, which can be done entirely in CSS:

@media (prefers-color-scheme: dark) {
    /* Dark mode overrides go here */

But it’s obviously very nice to give the player the option to toggle it themselves! (Although if you want to support both, ie. respect the user’s preset mode preference but also allow them to toggle it, it’s even more complicated.)

1 Like

Whether light on dark or dark on light is better varies not just by person but by device and lighting conditions. I’ll take dark on light on an e-ink device every time. On LCD I usually prefer light on dark.

In general, I think it’s a travesty whenever users can’t select their font, font size, colors. Especially when it can make something entirely inaccessible to some people. I can imagine a game with elaborate typography and/or textual special effects where an accessible version would implicitly be an adaptation… but if such a game already exists, I haven’t seen it. I haven’t played any IF where I’d consider it to be a good trade-off to exclude people because your color choices are too precious to allow changing them.

I also know painfully well how hard it is to get people to care about digital accessibility issues when it’s literally part of their job, so it’s not going to be an easy sell for hobbyists giving away games for free to put more time and effort into it. So I hope that people writing IF development / game playing software will keep these issues in mind and default to allowing flexibility on these grounds. (Yeah, I know that those are often people giving away things for free, too.)


I agree. For example, CoG games let you select from light, dark, and sepia themes, and also lets you select font size… but it doesn’t let you select the font itself. This is really unfortunate because it uses a serif font that I don’t really care for and it wears on me after a while, which causes me to stop playing even when I want to play more. It’s especially unfortunate because this seems to be completely out of the hands of the authors and is up to the app creators to correct (at least on mobile).

To be clear, I did figure a small amount of code would be involved; my hope was to provide the template, the code, and instructions on how to implement them in your Twine game, to give people a very easy way to include this option if they want to. This would pretty much be in the selfish hope that making it low-effort would make people more likely to go “well, why not?” – though I do think I’d probably have to advertise it in other Twine authoring spaces, not just here, to get much uptake.

I agree that it would be ideal for authoring systems to have this built in (as well as interpreters, but I think most interpreters have it built in already), but it would be nice to have some options for individual creators to implement it in the meantime.

And yeah, it’s definitely good to provide the player with some font options, when possible, and that’s another area where there can be competing access needs – I’ve seen a few games over the years that use OpenDyslexic, for example, which is a very well-intended decision, but the variable line weights are another thing that my eyes don’t do well with. Pygmalion, in this year’s Spring Thing, included an option to toggle between its retro video game font and a nice plain sans serif, and I appreciated that a lot. I’d love to see more games take that up.


Well-intentioned, but badly researched. :grimacing:

PSA time, everyone. There is way too little research still, but here’s where the evidence available points:

A clear, clean sans serif like Arial or Helvetica offers best results for people with dyslexia, better than OpenDyslexic. So long as it’s roman; people with dyslexia do much worse with italic type, so please reconsider using it for anything but short phrases at most. I feel safe in substituting other good sans serif faces, but Arial and Helvetica are the ones for which there’s actual data. (I look forward to eventually seeing data for Atkinson Hyperlegible.)

It’s to be hoped you’re already thinking about avoiding foreground/background contrast that’s too low, but on a display, the highest possible contrast of pure black text on a pure white background creates problems for people with dyslexia, too. And I wish I could tell you what’s optimal, but we don’t know. Black on something a little off-white like #FAFAC8 or a pale rose or peach or other warm pastel seems like the best bet.

Use a line height that’s 150% of the font-size. Stick with ragged right; don’t justify both margins. (Justifying the margins work out ok in newspapers and magazines and books because they actually have professionals scrutinizing it and hyphenating things so there’s something like consistent space between words.)

When writing CSS use rems (the “root em” unit) to specify sizes so it automatically respects the user’s font-size choice.

There’s a lot more, but these basics will get you pretty far.


This is an excellent and very informative thread.

With very low vision and dyslexia, I have a vested interest both with reading and coding.

Thank you!

1 Like

Budacanta uses the Andika font*, which is also supposed to be a dyslexia-friendly font. It doesn’t allow italic or bold modes (at least, the version I’m using doesn’t), which automatically prevents any habits involving using them for emphasis. I’ve had complaints that it looks a bit child-like, which would be another reason to allow font changing.

Unfortunately, I don’t think Ren’Py allows line height change (if it does, I don’t know about it).

    • Another area where I hope to have font choice but cannot yet provide it due to not knowing how to program the choice slider. Though in this case I originally decided that due to translations requiring extra fonts that had some overlap in certain languages - accessibility was a bonus.
1 Like


I know next to nothing about Ren’Py but the manual has a line_spacing property which I suspect is what you’re looking for…?

Oh, excellent! I’ll note that down and investigate :smiley:

Andika’s reminiscent of Comic Sans, which some people with dyslexia like, so maybe it’s okay… but I’m not seeing any data. OpenDyslexic touts how it was designed to help, but actually does a worse job at its stated purpose than some ubiquitous typefaces. People with dyslexia are better served by the person who’s been defaulting to Helvetica since the '90’s than they are by the person who picked OpenDyslexic because they wanted to be helpful.

That’s made me really skeptical of noble design goals without any demonstration that the creators ever tested whether they met those goals.

The primary design goal of OpenDyslexic is to provide a free alternative to (commercial) typefaces like Dyslexie.

That said, more recent research has more or less disproven Dyslexie’s claim of being easier to read…

1 Like

I did a whole bunch of testing between sans serif fonts last night and I found that I like Roboto the best with Helvetica coming in a close second. They’re both really similar but Helvetica has slightly larger word spacing which messes with my eyes a little bit. But maybe the spacing helps dyslexic people?

I’m not dyslexic so I’m just basing my preference on how quickly and easily I can scan a paragraph for a word, or read a paragraph without noticing the font or it slowing me down in some way. It’s not very scientific, but Roboto came out in top for me.

I’d like to incorporate it as an option in my game, so I’m interested in hearing what dyslexic readers think of the font. You can get the font off Google’s font repository.