Which Steam Accessibility Tags Can Your Visual Novel Honestly Claim?

If you are preparing a Steam store page for a visual novel, there is a small form in Steamworks that deserves more attention than it usually gets. Under Edit Store Page, on the Basic Info tab, Steam asks a series of questions about accessibility. Your answers become labels in a collapsible panel on the right side of your store page, and players can filter Steam search by them.

The form is optional. Valve says developers are "highly encouraged" to fill it in (Steamworks announcement, January 21, 2026), and by that date more than 22,000 apps had already done so. For a visual novel, the question is rarely whether to fill it in. The harder question is which boxes you can tick without promising something a player will find missing ten minutes into your game.

A wrong tick costs more than an empty one. A player who searched for a specific feature, bought your game because of it, and then discovered it was not really there has a good reason to leave a negative review and ask for a refund. This guide turns the questionnaire into a short test plan, so every label on your page is backed by something you actually checked.

What changed in January, and why does it matter for visual novels?

Steam first introduced the accessibility questionnaire in 2025, and outlets such as GamesIndustry.biz covered the launch as a way for disabled players to search for games by feature. On January 20, 2026, Valve revised the categories based on feedback. Two changes speak directly to our genre.

First, a new Input tag called "Playable at Your Own Pace" was added. Steamworks documentation describes it as players being able to take as long as they need for any input, and names "a visual novel with no timing elements" as an example (Steamworks Accessibility Features). Second, a new Visual tag called "Playable without Vision" arrived, and the announcement mentions visual novels with good screen reader support as the kind of game it was meant for.

The same update renamed "Playable without Timed Input" to "Playable without Quick Time Events" and added "Contrast Controls," a separate tag from color alternatives. So if you filled in the form before January, it is worth opening it again. Valve's own advice for affected games is simply to retake the questionnaire.

Which tags are easy to earn, and which are easy to overclaim?

Most visual novels start with a structural advantage: reading is self-paced by default. That does not mean every tag is automatically true. Sorting the list into three groups makes the job easier.

Usually within reach. "Playable at Your Own Pace" fits most visual novels, as long as nothing in your story runs on a clock. Check for timed choices, auto-advance that cannot be turned off, and minigames with reaction windows. The documentation specifically recommends avoiding timers on narrative text and dialogue choices. "Playable without Quick Time Events" is similar. "Mouse Only Option" is also common, but verify every menu, including settings and the save screen.

True only if you built it. "Save Anytime" asks for more than a save menu. Steam's guidance describes both manual and automatic saves in separate slots, with autosaves never overwriting manual ones. "Custom Volume Controls" means independent volume for types of audio, such as music, sound effects, and voice, not a single master slider. "Adjustable Text Size" comes with a concrete target: allow text to scale up to at least 38 pixels tall at 1080p. "Subtitle Options" matters if your game has voiced lines, and it asks for speaker identification and a background box with adjustable opacity. "Keyboard Only Option" means every action, including menus and the backlog, works from the keyboard.

Easy to overclaim. "Playable without Vision" and "Narrated Game Menus" are where good intentions most often turn into false labels. So is "Color Alternatives," if an affection meter or route indicator depends on color alone. "Camera Comfort" needs a check too: a visual novel has no free camera, but screen shake and flashing transitions still count, and the tag asks that players can reduce or disable them.

What does "Playable without Vision" actually require?

Steam's definition is strict. A blind player must be able to play the whole game without ever seeing the screen. The documentation adds a warning worth copying into your notes: if menus are narrated but the core gameplay still requires sight, do not apply this tag.

For a visual novel, the core gameplay is reading text and choosing. That makes the tag reachable, but only if every piece of information that reaches a sighted player also reaches a listening one. If you ship with Ren'Py, the engine gives you a real starting point. Its self-voicing mode, toggled with the V key, reads dialogue and interface elements aloud through the operating system's speech synthesizer. The accessibility menu opens with Shift+A, and a clipboard mode (Shift+C) sends text to other assistive tools (Ren'Py Self-Voicing documentation).

The engine only reads what is there, though. A wordless scene where a letter burns, a character who appears only as a silhouette, or an image-only button all go silent unless you give them text. Ren'Py provides tools for this: an alt property for interface elements, and descriptive text that is spoken only when self-voicing is on. Somebody still has to write those lines, and that somebody is you.

The honest test is simple and a little humbling. Turn on narration, close your eyes or cover the screen, and play from the title screen to one full ending. Do not peek, and have a second person watch for moments where you got stuck. If you needed to see even once to continue, the tag is not ready yet. "Narrated Game Menus" may still be accurate, and that is a perfectly useful label on its own.

How do you turn the questionnaire into a test plan?

Treat each tag as a claim and each claim as a test. Here is a sequence that fits into an afternoon for most projects.

1. Test the build players will get. The questionnaire describes your Steam release, not your editor preview. Install the actual package and use a fresh save.
2. Walk through the form once without ticking anything, and write down every tag you think applies.
3. For each tag, write one sentence stating what a player can do, then play the exact path that proves it. For "Adjustable Text Size," raise the size to the maximum and read a long line in the busiest scene. For "Keyboard Only Option," put the mouse in a drawer and go from launch to the credits.
4. Mark each result as pass, partial, or fail. Tick only the passes. A partial result is a to-do list item for your next update.
5. Keep the notes with your release files. When a later patch changes menus, audio, or the text box, re-run the affected tests before you touch the form.

This record also helps with players. When someone asks whether your game supports a screen reader, you can answer with what you tested and on which platform, instead of guessing.

Where does Novelez fit?

Novelez does not fill in the Steam questionnaire for you, and it cannot certify that a game meets any tag. Menu narration, text scaling, and keyboard handling in a Steam build depend on the engine and package you ship. Those need to be tested in that final package.

What Novelez helps with is the part many accessibility problems start from: the story's structure. In the block editor you can see whether any choice relies on a timer, whether a key moment is carried only by an image or a sound effect, and whether a scene ends on a visual beat that a listening player would miss. Preview can start from any selected block, so after you add a line of narration to a silent scene, you can replay just that moment instead of the whole route. Fixing these at the script stage is much cheaper than discovering them during the eyes-closed test a week before release.

If you are about to fill in the form, pick one tag you feel confident about and run its test today. Which one turned out to be harder to prove than you expected: text size, keyboard play, or narration from start to end?