When I joined the Toxic Yuri VN Jam, I had 3 main goals in mind:

1. Make a cool story featuring my Duskpuppy girls (characters co-created with Robin Nightmares, although they didn’t participate in the jam with me)
2. Learn how to publish a game on itch.io
3. Learn how to make and implement as many accessibility settings as possible & promote accessible game design

Goal #2 was a success, and #1 is a semi-success (I’ll count it for real once 1.0 is actually finished!)

Goal #3 ended up being what took the greatest amount of attention and effort on my part! It’s still a WIP as I add more features and refine the ones that are broken, but I’m extremely proud of all the work I put into making it happen. Even if it took away time from developing other aspects of the game, I would not have been happy if I had cut corners on this part of the project. 

Many other games in the jam have no accessibility settings, or only have those that come default with Ren’py. I don’t blame anyone for this as working within the confines of a game jam deadline is already hard enough, let alone for those who were making their very first game (or very first Ren’py game... as was the case for me.) 

But now I have arrived at the second part of goal #3: to promote accessibility in games, share what I learned (maybe learn how to do things better!) and hopefully inspire other devs, inside and outside the jam, to include some options like these as well!

This post will be more of a discussion of the features I implemented, a bit lighter on technical details. Once everything is in place and working properly, I will make another post with all the specifics. 

Table of Contents:

1. Respecting disabled players’ right to knowledge
2. Ren’py’s Accessibility Menu
3. Visual accessibility
4. Audio accessibility
5. Other accessibility
6. Further resources

1. Respecting disabled players’ right to knowledge

By this I mean simply: Will a disabled player be able to tell, before buying or downloading your game, whether or not it is accessible to them?

Many of us understand the concept of content warnings and have provided some examples on our store pages so that players can decide whether such content is safe for them to view. But likewise disabled players should know ahead of time:

• Whether audio is required to proceed, and if captions are provided
• Whether image captions are provided for screenreader support (or, if using Ren’py, its built-in self-voicing mode)
• Whether adjustments can be made to text size, font, color, window opacity, or size of UI elements
• Whether there are flashing, blinking, or shaking images, and if those visual effects can be turned off

And so on. Of course there are infinite accessibility needs that can’t all be predicted by devs, and I encourage you to think through the ones that might apply to your own game, but if for whatever reason you cannot provide an accessibility setting, stating it clearly on the store page will let players know before they try and fail to play your game, much like providing content warnings will help people steer clear of content they can’t handle. 

The Game Accessibility Information Symbol was created as a way to guide players towards information that can help them decide whether to purchase a game based on accessibility needs. 

It is critical that this information be clear, upfront, no more than a single click away, and legible (easy-to-read font, accessible to screenreaders, and possible to enlarge such as through browser zoom). The information must not itself be a barrier to access!

2. Ren’py’s Accessibility Menu

Many of us VN devs used Ren’py in our projects, but did you know it comes with a menu (accessible with Shift+A) that lets the player override some of the creator’s default settings?

These options include font override, high-contrast text (white on black... which is unfortunately less accessible to me. One more reason to consider lots of different options!), text size and spacing override, and self-voicing toggle. Self-voicing is Ren’py’s own built-in screenreader and can also be activated by pressing V at any time. The most recent version of Ren’py also has a “force stereo audio to mono” setting but my project broke when I tried to update so for now that one is not possible for me.

While anyone can use Shift+A to access the menu, I recommend making it explicit in your own preferences screen by making a button with the action Preference("accessibility menu"). Most players have no idea this menu exists and there’s no reason to hide it from those who need it most!

3. Visual Accessibility

This one covers a lot of ground, from complete blindness to partial blindness, to disorders like glaucoma, cataracts and others, to colorblindness, to photosensitivity... As usual, there’s no one-size-fits-all solution, but you can think about some ways to make things easier for most people.

Self-Voicing

As mentioned above, Ren’py comes with its own self-voicing mode. I recommend reading the documentation yourself, but at a very basic level, tags like {alt} can be used to add additional context for players who can’t see images, {noalt} can be used to exclude words from being voiced (for example a keysmash that a screenreader can’t parse), the alt styling can be used to add alt text to displayables such as buttons, icons and gallery images, and the alt character can be used to make lines available only during self-voicing mode.

Many blind players enjoy Ren’py-made visual novels thanks to self-voicing mode. With your help, they can be made even more accessible!

Of course, screenreading isn’t all there is when it comes to visual accessibility. You can also give options to adjust things like fonts, colors, window opacity, and size of UI elements.

Font Choices

For Beaconing, I knew I wanted to go with a striking typewriter-style font (Leorio), but I also knew it wouldn’t be easy or pleasant for everyone to read. Thus one of the very first things I implemented was the font choice toggle. Everyone will have their own preference as to which type of font is easiest to read, so I erred on the side of too many choices, not too few!

The options I provided are as follows:

• Leorio: The stylish typewriter font that fit the story vibe I was going for.
• OldNewspaperTypes: Another stylish font, an alternative for people who want to keep the old-timey vibe but don’t like Leorio for whatever reason. 
• Libre Baskerville: A clean serif font with good readability. I feel it’s still fitting with the stylish presentation while being fairly neutral itself. A good option for those who like serif fonts.
• DejaVu Sans: It comes default with Ren’Py so why get rid of it? The option is there for those who prefer sans-serif fonts. 
• Atkinson Hyperlegible: This font was developed by the Braille Institute to be easy to read for those with low vision. All letterforms are distinctly designed, so those with blurred or obscured vision can have an easier time making out similar glyphs. 
• DyslexicLogic: Developed to help readers with dyslexia, it is similar in appearance to Comic Sans, which is widely used by many dyslexics as a preferred font. It clashes quite severely with the intended tone of the story, but I hope its inclusion makes things easier for someone.
• OpenDyslexic: A widely-used font for readers with dyslexia (it even comes as a font override in the Ren’Py Accessibility Menu). It has bottom-weighted, uniquely designed letterforms that some people find easier to distinguish. However, it doesn’t work for everyone, so I wanted to provide multiple legible options beyond just OpenDyslexic. 

UI Sizes and Colors

Designing a decent-looking UI can be challenging. Giving the player options to change text size is a huge accessibility feature that should not be ignored! Luckily for Ren’Py users this come with the Accessibility Menu, but those using other engines should allow this option as well. It is possible for text sizes to break intended layouts; accounting for this in the design phase is ideal, but even if it breaks the layout a little, this trade-off can be the difference between someone reading your VN or not at all. 

On top of that, text colors, outlines, drop shadows, window colors, and window opacity can all have a profound impact on legibility, which is especially important for text-heavy visual novels. I went with a NVL-style presentation for Beaconing, with lots of paragraphs of prose, so I knew this needed to be accessible with the least amount of friction possible.

Ironically, I wanted white text on a dark background for Beaconing’s moody and spooky tone… which is one of the least accessible combinations for my visual impairment! Knowing this, even if it meant sacrificing my artistic vision, I made it a mission to include enough color and opacity options to allow for more legible “light” modes. As of this writing I have not fully solved all the problems that have come up for this implementation. Drop shadows keep breaking for reasons I don’t understand, and the way Ren’Py handles NVL-mode backgrounds has also been complicated to sort out. But I will have a functioning UI color system by the 1.0 release, this I vow!

Text contrast isn’t the only thing to keep in mind; depending on what kind of visual information you’re conveying, a “high contrast” mode can help distinguish things like character sprites, object, and backgrounds. I have attempted to include brightness and contrast sliders in Beaconing, but they currently have a big problem that can render the game unplayable: if you change the sliders too severely, you might make the UI invisible and be unable to revert the changes. Ideally they should be present with safeguards to prevent that scenario.

Another possible consideration is an eyestrain filter: An overlay that can smooth out severe color contrasts and make them easier to look at for longer periods of time. 

Colorblindness

The simplest rule here is: Never use color alone to convey important information. 

For us color-sighted people, color-coded icons are fast and easy to parse, but for colorblind people, they can be difficult or even completely impossible to distinguish! 

I actually grew up with two colorblind people in my family: My dad and my brother. From a very young age I learned to label all the color pencils and name colors specifically rather than just assuming the person looking at it knows them. This habit is so ingrained in me I still use symbols when color-coding notes to myself, even though I know I can differentiate colors… just in case someone happens to need to look at them later.

That’s one major accessibility feature: Always use an easily-distinguishable symbol alongside color-coding. Avoid symbols that could be easily mistaken for each other (colorblind people can have other visual disabilities, after all). 

When designing backgrounds, characters, or UI, check that the contrast between all elements is high enough that they can be understood even in a completely B&W environment (note: there are different ways to generate B&W images that don’t always follow the same contrast rules. Try a few differents to ensure results are consistent across the board.)

Allow the player to pick their own color choices for the UI, especially if things need to be labelled. While some curated presets can be helpful, remember that everyone’s eyes are different and what works for one person might not work for another, so allowing finer control over color choices can help with that.

Do NOT apply “colorblindness filters” that change the entire screen! These are almost always simply simulation filters that are meant to show you what having that form of colorblindness is like. They can be useful in the testing phase but never as useful as playtesting with actual colorblind people. On the rare occasion that a filter is meant to actually help, it is never as helpful as just designing smartly and allowing the player to pick their own colors. 

Visual Effects

Options to turn off screenshake, flashes, and other VFX can make a huge impact on accessibility for many with photosensitive conditions. 

The first thing that comes to mind is epilepsy, and it is true that this is one of the more severe disabilities affected, but you must not let it limit your view of which VFX might be harmful. Just because your game passes a Harding test does not mean it is safe for all photosensitive conditions (or even all epileptics). 

Visual effects that can trigger seizures, migraines, eye strain, pain, dizziness, motion sickness, tics, or other conditions include:

• Screen shake
• Jittering objects, sprites, windows, or text effects
• Line boil (animated outlines)
• Sparkles/Shimmers
• Speedlines
• Motion blur
• Flashing
• Strobing
• Blinking lights or icons
• Rapid color changes
• Scrolling patterns
• Environmental effects (rain, snow, fog)
• Parallax motion
• And many more!

Including options to disable or decrease the frequency of VFX can help mitigate the worst outcomes. If an effect cannot be disabled, it must be warned for (and the more specific the warning, the better!)

In Beaconing, this was one of my first considerations: I wanted to include an option to disable the click-to-continue icon animation. This ended up being a huge ordeal that isn’t fully solved yet, but I’ve seen firsthand how something as simple as an animated icon can trigger painful tics in someone with Tourette’s. The effort is worth it!

4. Audio Accessibility

At the bare minimum, there should be no reliance on audio-only for things like puzzles, spatial orientation or narrative branching. Audio can be a great way to promote immersion and storytelling in games, especially for VNs where text and images already do so much heavy lifting, but there should always be alternatives provided for those who cannot enjoy or perceive your sound design. 

In the broadest sense possible, the game should still be engaging even without any audio!

Volume Sliders

These come default with Ren’Py and are the bare minimum, really. Separate sliders for music, sound effects and voices are standard, but if you really want to, you could add even more sliders for even more specific categories of sound.

Sound effects can be unpleasant, grating or even triggering for some people. Allowing them to disable individual sound effects, such as typing noises, wet/smacking noises, sirens/loud/high pitched noises, gunshots, thunder, dogs barking, and many others, can allow more players to enjoy the work while not necessarily muting all sounds.

Subtitles, Captions, and Transcripts

These features are absolutely essential for deaf and hard-of-hearing players and can be useful for others as well; nobody wants to miss important information that was conveyed only through audio.

Subtitles provide legible text for dialogue and song lyrics. All considerations made for visual disabilities should also be made for the formatting of the subtitles: sizes, colors, contrast, font, etc. 

You can also help distinguish speakers by giving the option to tag each line with the speaker’s name, as well as color-code different speakers. This should always be optional, since these features will not be accessible for everyone.

Captions describe sound effects and music beyond just what the dialogue is saying. You don’t need to caption every tiny little sound detail, but important sounds such as screams, claps, gunshots, things happening off-camera, and anything conveying story information must be described. Changes in intonation (for example, sarcasm or fear) must also be indicated alongside dialogue. Captions can be an option separate from subtitles, since not everyone who needs subtitles will also need captions. 

Formatting and timing of subtitles and captions is a delicate matter; line breaks can affect readability, and there’s a limit to how many characters per second can be onscreen before the timing is too fast to understand. Look up professional captioning guidelines for your language and try to follow them as closely as possible; don’t leave it up to autocaptioning to decide these things for you! Always proofread carefully (although if you wrote your own dialogue you probably don’t need to worry about mishearings).

For Beaconing, I provided separate sound effect and music captions, which use Ren’Py’s “notify” function to alert the player when a change in sound has occurred. I do not have any cutscenes that necessitate dialogue subtitles. 

Transcripts are another good option to have, especially in audio-heavy works. Reviewing what was said afterwards can also help in memory retention. They should not serve as a substitute alone for subtitles or captions, but as another way to help players understand what was said and to refer to later.

Much like in the case of colorblindness, anything that has an audio cue should also have a visual cue of some sort as an alternative. Puzzles should be solvable even with no audio at all.

Stereo vs. Mono Audio

Most sound and music produced nowadays is mixed in Stereo mode, with separate left and right ear channels. Some people may be deaf or hard-of-hearing in only one ear, and thus miss out on sounds mixed through that channel. Forcing sound into Mono can allow them to enjoy the full extent of the sound design using their remaining hearing. 

The most recent version of Ren’Py includes this as a built-in preferences action as well as an Accessibility Menu override. Unfortunately my project broke when I tried to update, so I will need to figure out this problem on my own. 

5. Other Accessibility

The above features are the most obvious when it comes to accessibility features, but there are still other categories to cover. Not all of these are directly relevant to VNs, but they are important to games accessibility as a whole, and should be considered depending on your game’s features.  

Control Supports and Remapping

I have to admit, I haven’t figured out whether this is possible in Ren’Py, or how to even begin allowing it if it is. But at the bare minimum, it allows keyboard, mouse, and gamepad support, which can cover a wide range of possible motor needs. 

Still, full remapping is the most flexible and most accessible, and I would love to implement it if I can figure out how it works. 

Windowed/Fullscreen Modes

This comes default with Ren’Py. Besides a matter of preference and comfort, windowed modes allow people to use accessibility software such as onscreen keyboard, magnifying glass, and screenreaders. 

Message History Log/Objective Reminders

Ren’Py has a history screen that saves previously viewed text, but for more complex games it can also be helpful to include some sort of journal that reminds the player what they were doing or a quest log that nudges them towards their next objective. 

Hint System/Walkthrough

Everyone gets stuck sometimes, and a simple hint system or included walkthrough can help get past difficult puzzles or achieve different endings. Some games use a multiple-tier system where hints start broad and vague but then become increasingly specific, sometimes ending with giving away the answer. This allows the player to decide how many hints they want before figuring it out on their own. 

Skip Puzzle/Cutscene/Action Sequence

Sometimes a hint won’t cut it. Skipping puzzles, cutscenes, action sequences, boss battles, etc allows players to decide the right amount of challenge they want, vs. just reading a story.

Content Notice/Warning System

Many people include a sensitive content notice on the store page, but it can also be helpful to include one in-game. You can give the option of receiving warnings on a scene-by-scene basis, as designed by Joanna Blackhart for “Ikenfell”. This is especially useful for streamers who want the chat to get a heads up for content at any time. 

As an aside, I generally prefer to refer to this as “notice” rather than “warning” because it feels less judgemental to me; sometimes it can feel demeaning to have your life experiences be described as a “warning” to others, and sometimes the content is a selling point more than it is a trigger. Keeping things relatively neutral helps people decide for themselves what they wish to see. 

6. Further Resources

Ren’Py resources:

Ren'Py Self-Voicing Documentation

Caption Tool for Ren'Py by npckc

Ren'Py Accessibility Add-On by Theo

Sound Disabler and Captions Tool for Ren'Py by Feniksdev

The Blind Nerd: Let’s Talk About Visual Novel Accessibility, Shall We?
The Blind Nerd: A Tips and Tricks Guide for Visual Novel Accessibility [And other Games]

Basic Ren'Py TTS Accessibility Guide by orangecarnation

Ren'Py Accessibility by wolfnose

Tips on making your VN more accessible by LadyIcepaw

Accessible Game Design:

Game Accessibility Guidelines (Website)

Game Accessibility Information Symbol (Website)

Designing for Disability (Youtube Playlist)

Access-Ability (Website)
Access-Ability (Youtube Playlist)

Can I Play That? (Website)

Able To Play (Website)

AbleGamers (Website)

GameAccessibilityNexus (Website)

Conclusion

I hope this post has been inspiring and that these resources are helpful in making your next project accessible to all players! With some knowledge, thoughtful design, and forethought, many barriers to access can be eliminated entirely, Give your players options to change colors, fonts and sizes, make use of Ren'Py's built-in tools, and provide audio and visual alternatives wherever possible, and your disabled players will feel welcome and included—and be able to enjoy your creative work, too!

I am still working hard, trying to get all of these systems working correctly in Beaconing. If you have any suggestions for additional features to include, please let me know!