By 
Around 6 months ago in April 2025 Valve announced that Steam would be getting its own form of accessibility store tags added to their digital PC gaming platform in the coming months.
Following in the footsteps of companies like Xbox and PlayStation implementing similar tag systems on their console stores, and shortly after the formation of the Accessible Games Initiative (a collective attempting to standardise naming conventions and language around accessibility tags), Valve would be launching their own series of tags alongside a developer facing setup wizard to help game creators identify which tags might best apply to their game.
Importantly to this story, Valve’s accessibility tag names and developer facing descriptions are custom. Valve is not aligning their accessibility store tag names and descriptions to match those of the Accessible Games Initiative.
Steam’s accessibility store tags went live over this past summer, and have generally been a pretty helpful addition to the store for disabled gamers. Players can select tags that may be important to their ability to play games such as “Save Anytime” or “Narrated Menus”, and filter out games that fail to meet their needs.
However, there is one accessibility tag on Steam that I believe is being applied to games that it doesn’t really belong on, and a big factor in this trend is Valve’s developer facing description of who should apply the tag to their games.
So, let’s talk about the “Playable Without Timed Inputs” accessibility tag on Steam.
I first became aware of this trend a couple of months ago back in September when covering the release of Hollow Knight: Silksong. I attempted to work out what accessibility support the game would feature based on a combination of Gamescom demo gameplay footage and the accessibility tags present on Steam. At the time I noted it seemed odd for this particular game to be tagged as “Playable Without Timed Inputs”.
Having since played through Silksong, I maintain that that tag is not appropriate for Silksong, a game that is going to be near impossible to complete for many disabled players with disabilities impacting motor control, coordination, or reaction timing. Multiple bosses are not going to be feasible to defeat without consistent and sustained accuracy in parry or dodge timing, multiple areas of the game require accurately timing precise jump inputs with minimal room for timing error, and boss fights that are a war of attrition are going to require rapid timed inputs of the attack button to get the amount of damage into small available windows that is needed.
More recently my cohost Arevya on Ctrl, Alt, Access pointed out that Dispatch, an episodic narrative adventure game about a super hero forced to work on the super hero dispatch department, also features the “Playable Without Timed Inputs” tag on Steam. While that game does allow the player to disable Quick Time Event button sequences, it does feature timed dialogue choices with no ability to increase the time available or disable the choice timer. These are, undoubtedly, inputs that need to be made under time pressure. This is an example of this game containing what I would call “Timed Inputs”.
There’s a number of other examples of this I’ve noticed over the past two months, but I’m less interested in pointing at specific examples and more interested in the overall trend. Why are games that I would argue require pretty clear timed inputs being tagged by their developers as “Playable Without Timed Inputs”?
Given that I was only really seeing this one tag incorrectly applied to games, and by multiple different developers under different publishers, my suspicion was that the cause of this might be based in Valve’s developer facing description of who should be applying the tag to their games. To me that made more sense than the idea that multiple different developers were independently having the same issue for unrelated reasons.
I asked around and found some game developers who were willing to send me screenshots of Valve’s developer backend setup wizard for accessibility store tags, showcasing how each accessibility tag is explained and described to game developers. For any developers not particularly versed in accessibility discussions, this was likely to be where they got their guidance on applying this tag or not to their game’s store page.
Playable Without Timed Inputs.
Sequences of precisely timed button presses (“Quick Time Events”) or button mashing can be uncomfortable or impossible for players.
Answer yes if your game doesn’t feature Quick Time Events, or if they can be disabled.
Is your game playable without Quick Time Events?
Yes, my game either has no quick time events or they can be disabled.
No, my game requires quick time events.
So, I think a few things very quickly stand out when reading this. Most notably, the way that the wording of the accessibility tag differs in meaning from what developers are told to consider when selecting whether or not to apply the tag to their game.
The player facing name of the accessibility tag is “Playable Without Timed Inputs”, which to me as a disabled player with a coordination disability encompasses a pretty wide range of accessibility support. I would expect playable without timed inputs to apply to games that truly do not require inputs to be precisely timed, be those things like narrow parry windows, input strings in a fighting game combo, or timed dialogue choices with minimal time to select your input.
Guitar Hero’s note track for example isn’t a traditional Quick Time Event, but I wouldn’t describe that game as “playable Without Timed Inputs”.
The developer facing description of this accessibility tag starts with a narrow scope (sequences of precisely timed button presses specifically in the context of Quick Time Events, or Button Mashing). It then shrinks that focus yet further.
Answer yes if your game doesn’t feature Quick Time Events, or if they can be disabled.
So now precisely timed inputs like fighting game combo strings are being set aside from this description, and so are button mashing sequences, previously mentioned, not part of the question you’re being asked here.
If you can disable Quick Time Events, then you should say you’re playable without timed inputs.
I suspect that by narrowing the meaning to such a tight definition here, and leaning on the term Quick Time Event which people have an existing preconceived idea of, Valve’s description is leading developers to apply the “Playable Without Timed Inputs” tag to their game in a way that is frequently not helpful to disabled players.
I personally feel like either the tag needs to be renamed on the public facing front end to better specify to disabled players that this tag is narrowly about disabling traditional Quick Time Event sequences, or the developer backend guidance needs to be rewritten to be more specific, broadening its definition to better encompass the wider range of “mandatory timed inputs” that might need considering as inaccessible in a game.
If anyone from Valve who is in a position to make changes happens to be watching or reading this, I would love to chat with you about ways that this could be reworded on the developer backend, to avoid some of the confusion currently taking place between developer and disabled player expectations.
I would suggest as a starting point looking at the Accessible Games Initiative and how they’ve approached their equivalent of this tag, Playable without Rapid Button Presses. While their initial description of the tag is short (Lets you avoid repetitive button actions like button mashing and quick-time events), they offer a PDF that goes into more specifics about who they feel should or should not apply the tag to their game. Their developer documentation dedicates a full page and a half to explaining what the tag should be applied to.
This requirement applies to:
• All rapid button presses, such as those required for executing combos (e.g., hitting X, then hitting Y within one second to execute a combo).
• Examples:
• Let players avoid sequences of one or more precisely-timed button presses (e.g., actions that require players to hit X within one second then Y within one second).
• Let players avoid rapid repeated tapping actions (e.g., hitting X 10 times within two seconds to lift a heavy object).
Tips & Context:
• It is good practice to avoid requiring rapidly repeated inputs of any type, such as waggling sticks to escape an enemy’s grab.
• Some events require multiple simultaneous inputs.
Simultaneous inputs are not part of the requirements for this tag, but it is still good practice to avoid these when possible.
While the above is still not a perfect blueprint for “Playable without Timed Inputs”, this developer facing description helps to catch things that might not look like traditional Quick Time Event sequences at first glance to a developer, if you’re focused on the physical ability to press buttons rapidly in close succession to each other. It’s a good description given that the name of the tag is specific to the rapid nature of sequential button presses. It even includes a mention that a single time sensitive input may be an issue.
But to me, “Playable Without Timed Inputs” also implies a reaction speed element, either cognitive or motor control related, even if the timed inputs are not sequential.
Is there a fundamental difference between “quickly tap A when it comes up to avoid damage” which might not be thought of as a Quick Time Event, and “Quickly press the button for the dialogue choice you want to select” or “Press the parry button with the right timing not to tank a big hit?
This is I think the biggest area of accessibility disparity between the tag’s current name and the developer guidance provided by Valva.
I think there’s a world where perhaps the solution to this issue is to rename the existing “Playable Without Timed Inputs” tag, and create an additional new tag option that encompasses some of these other elements, to perhaps better clarify what support is or is not being offered to disabled gamers with a specific tag.
While there’s a few different possible solutions to this problem, at the end of the day I think there is an issue here. Multiple developers are using this accessibility tag on Steam in a way that is not aligning with disabled player expectations for what that tag should mean, and for it to be effective we need to make some changes to bring its tag name and developer guidance more in line with each other.
By 
