Liza Bhadana

Posted on Aug 7

200 game pages, 200 star ratings, 0 machine-readable controls

#webdev #gamedev #a11y #seo

A player lands on your game's page. Before they commit any attention to it they want one thing answered: do I have what this needs? A keyboard, a mouse, a thumb. On a phone that question is the entire decision.

Now look at what the page actually gives them. A star rating. A rating count. A genre list. A developer name. A publish date. A play button.

I went and counted. Across 200 game pages on four different browser-game portals, every single one publishes a star rating. Not one publishes the machine-readable field that says what you need in your hands.

That field is not missing from the standard. schema.org defines it, it is valid on every game page on the web without an extension, and it goes in the same JSON-LD block that already carries the star rating. It is missing from the practice, and the reason turns out to be worth a developer's time: nobody upstream is ever asked for it.

The short version

200 game pages, four portals. 0 carry any schema.org accessibility property. 200 carry aggregateRating.
schema.org's own usage stats: aggregateRating is on 1M–10M domains. accessibilityControl — the field for "what input fully drives this" — is on 1K–10K.
The data isn't hidden, it was never collected. 190 of 190 supplier pages have a "How to Play" section; only 107 name an input device anywhere in it. Of the 38 games where we hold no control text at all, 3 have an upstream section that names a device.
The supplier's device flag is not a substitute. 182 of 190 pages claim mobile support; for 118 of those, the supplier's own how-to-play text never mentions touch.
One platform gets this right, and it is the one that asks the developer directly. itch.io has 25 input methods in its taxonomy and 65,185 HTML5 games declaring a keyboard.
We shipped a fix into our own build: 96 of 200 game pages now emit accessibilityControl. The other 104 emit nothing, on purpose.

What I measured, and what these numbers are not

Every figure here is a count of published metadata — what a page says about a game. None of it is a count of behaviour. No game in this article is described as broken, or as working. Games here run inside a cross-origin frame drawing to a WebGL canvas the host page cannot see into; screen captures of that region come back solid black even while the game runs perfectly, and asking the host document how many canvases exist returns zero. That trap has cost us a full day before. "The page documents X" is the strongest claim this evidence supports, and it is the one I am making.

Three guards, because a measurement can be perfectly real and the conclusion still wrong.

The wrong-game guard. Our internal slug for a game is not the supplier's slug — for 38 of 200 entries they differ — and requesting the supplier's page with our slug returns HTTP 200 for a completely different game. Every upstream slug here is derived from the game's own embed URL, and every fetched page is rejected unless the name in its JSON-LD matches the registry title exactly. 190 of 190 passed; 0 were rejected. Fetching a real page under a deliberately wrong expected title was also tested, and the guard rejected it.

The detector-fires guard. A checker that never fires is not a checker. The property scanner was run against a document that definitely contains accessibilityControl (schema.org's own page for it — detected) and against one that definitely does not (example.com — not detected).

The negative control. Two of them, and one of them changed a number in this article. On itch.io, itch.io/games/zzz-fake-filter-xyzzy returns 404 — good. But itch.io/games/html5/zzz-not-real-xyzzy returns HTTP 200 with the full unfiltered game count. An unknown filter is silently ignored rather than rejected. So "the filter URL returns results" proves nothing there; only "the filter returns a count different from the unfiltered total" does. Every itch figure below passes that stricter test.

And one I got wrong and had to fix mid-run, recorded because the fix is the useful part. My first device detector looked for the literal strings wasd, arrow keys, keyboard and spacebar. It therefore scored these two control lists as naming no keyboard:

Hazmob FPS: Online Shooter  —  "W, A, S, D — move | Space — jump | Shift — run | C — crouch"
Driver Club: Highway Racing —  "W or up arrow — accelerate | S or down arrow — brake"

Both are obviously keyboard games. I found it by hand-reading the eight games the aggregate had flagged as odd, not by trusting the total. The corrected detector ships with a fixture set of 24 strings — 16 that must be detected and 8 that must not — and refuses to print numbers if any of them fails.

The field has existed the whole time

schema.org's accessibilityControl is defined as:

Identifies input methods that are sufficient to fully control the described resource.

It is a property of CreativeWork. VideoGame inherits from Game, which inherits from CreativeWork, so it is valid on every game page on the web with no extension, no vendor prefix and no negotiation.

The values come from a W3C community group vocabulary (current version dated 26 March 2026), and there are six:

Value	Meaning
`fullKeyboardControl`	Users can fully control the resource through keyboard input
`fullMouseControl`	…through mouse input
`fullTouchControl`	…through touch input
`fullSwitchControl`	…through switch input
`fullVoiceControl`	…through voice input
`fullVideoControl`	…through video input

Two of those six answer the question a player actually has. fullKeyboardControl means you will need a computer. fullTouchControl means your phone is enough.

Now compare how much the game vocabulary is used. These are schema.org's own published usage figures, from Google's web index, as printed on each term's page:

schema.org term	Domains using it
`aggregateRating`	1M – 10M
`genre`	100K – 1M
`VideoGame`	10K – 100K
`gamePlatform`	10K – 100K
`playMode`	10K – 100K
`numberOfPlayers`	10K – 100K
`accessibilityControl`	1K – 10K
`cheatCode`	< 1K
`gameTip`	< 1K
`quest`	< 1K

Ratings are published on somewhere between one hundred and one thousand times as many domains as the field for "can this person operate it". accessibilityControl sits one band above cheat codes.

200 pages, 200 ratings, 0 accessibility properties

I fetched every game page I could verify: 191 on Playgama (190 derived from our own catalogue's embed URLs, plus one more), 3 each on CrazyGames, Poki and Y8. Every page was confirmed to be a real game page before being counted, and every one was checked for all six accessibility properties plus accessMode and accessModeSufficient — searching the whole document, not just the JSON-LD, so microdata and RDFa would have been caught too.

Portal	Pages checked	With `aggregateRating`
Playgama	191	191
CrazyGames	3	3
Poki	3	3
Y8	3	3
Total	200	200

Three more portals returned unknown, not zero, and they are listed as unknown: Newgrounds would not respond to the fetch at all, and Armor Games and GameDistribution render their game links client-side so no game URL could be discovered from the homepage HTML. I would rather report three gaps than pad a round number.

The data isn't hidden. It was never collected.

The obvious next thought is that portals are dropping information the developer supplied. That is not what is happening, and this is the part that changes what a developer should do about it.

Every one of the 190 supplier pages has a How to Play section. All 190. That field is fully populated — somebody wrote prose for every single game.

Only 107 of those 190 sections name an input device anywhere in them. The other 83 describe the goal, the modes, the progression and the vibe, and never say what you press.

It gets sharper. Our catalogue holds no control text at all for 39 of 200 games. That has sat on our backlog as a data-entry job — go and fetch the missing controls. So I went and fetched them: 38 of those 39 have a live upstream page, all 38 have a How to Play section, and 3 of the 38 name an input device in it.

There is nothing to fetch. The gap is upstream, and no amount of effort on our side closes it. That reframes a backlog item as a supplier problem, which is a cheaper thing to know than to discover slowly.

The device flag is not a substitute, and it is only safe in one direction

Every supplier page carries availableOnDevice, and 182 of the 190 say Desktop, Mobile, Tablet. If that were trustworthy the whole problem would be solved.

It is not trustworthy in the affirmative. For 118 of those 182 games, the supplier's own How to Play section never mentions touch, tapping, swiping or an on-screen control. The same page asserts phone support and then explains the game entirely in keys. One of the two is wrong and the page gives you no way to tell which.

The negative direction held up perfectly, and that is genuinely useful:

`availableOnDevice` says	Pages	Documents touch	Has controls, names no touch	No control text at all
Desktop, Mobile, Tablet	182	71	74	37
Desktop only	8	0	7	1

Eight games are flagged desktop-only, and not one of them documents a touch control. Trust the "no". Never trust the "yes". That is the rule we use, and 190 pages is the largest sample we have tested it on.

Please also note what is not in this article: the star ratings. They are right there on every page, they would make the catalogue look busier, and copying a supplier's rating into your own markup is asserting that those reviews were left on your site. They were not.

Our own blind spot, which is worse in one specific way

None of the above lets us off. Here is our own catalogue, measured the same day:

200 entries. 161 have control text. 39 have none.
Of the 161, 39 more have control text that never names a device — flavour, objectives, scoring.
So 78 of 200 — 39% — tell a player nothing about what to hold, either way.
Where a device is named: keyboard 75, mouse 64, touch 74, gamepad 0.

And then the tags, which is the part I did not expect. The catalogue carries 182 distinct tags. Exactly two of them name an input device: mouse (19 games) and point and click (7 games). (A third, arrows, matched the detector and turned out to be about the puzzle pieces in Arrow Exit Puzzle. Hand-checked and discarded.)

There is no tag for a keyboard. There is no tag for touch. There is no tag for a gamepad.

Tags are what filters, related-game rails and internal search are built from. A vocabulary of 182 terms that can say beauty salon, backgammon and horde survival, and cannot say keyboard, is a vocabulary in which "show me games I can play on this phone" is not an expressible query. Not hard — impossible, until someone adds the word.

One platform does collect it, and the reason is not technical

itch.io asks developers to tick their game's input methods when they publish it. Not a free-text box: a list of 25 input methods, from Keyboard and Touchscreen down through Dance pad, Eye tracker, Gyroscope and Stylus. Every one is a browsable filter.

Measured today, browsable and countable by anyone:

itch.io, HTML5 games	Count
All HTML5 games	710,347
Declaring Keyboard	65,185
Declaring Mouse	54,464
Declaring Touchscreen	17,959
Declaring Gamepad (any)	8,680
Declaring Smartphone	6,491

Be honest about what that shows. 65,185 out of 710,347 is about 9%. Roughly nine in ten HTML5 games on itch.io still declare nothing about a keyboard, and touchscreen is declared on 2.5%. The field existing is not sufficient.

But 65,185 is not zero, and zero is what every other portal in this study returned. The difference is not technical — schema.org's field is free and universally valid, and itch's field is custom and non-standard. The difference is that one of them asks the person who knows. Nobody has to reverse-engineer the input method of a game whose developer ticked "Touchscreen" at upload time.

Three itch.io pages were sampled at random for this study alongside the other portals. None carried a schema.org accessibility property either — itch's input data lives in its own database and renders as a table row, not as markup a search engine can read. One of the three had an Inputs row filled in (Inputs: Keyboard). That is one more than the 200 pages on the other four portals managed between them, and it is also why the headline figure in this article says 200 rather than 203: I did not want a counter-example quietly padding a zero.

What we shipped today

Writing this without changing anything would have been cheap, so the generator that builds every SlowDen game page now emits accessibilityControl. 96 of 200 game pages carry it: 70 fullTouchControl and 26 fullKeyboardControl.

The other 104 emit nothing, and the rule for that is the interesting part.

The approved values assert that one input fully drives the game. A control list that names WASD and a mouse supports neither claim on its own, so those games get nothing. What we do emit:

fullKeyboardControl — the 26 games on a hand-verified list where every documented control is a keyboard key and no touch alternative appears anywhere in the text.
fullTouchControl — 70 games whose control list names a real touch input (tapping, swiping, dragging, an on-screen joystick) and which either names no keyboard at all, or also names a mobile device, which is the shape of a list documenting two complete schemes, one per device. All 26 borderline cases in that second group were read by hand before this shipped.

Mouse is deliberately not emitted, even for the games that look mouse-only. Keyboard false negatives are real — I produced two of them this morning — so "mouse only" is a verdict resting on the least reliable of the three detectors. Skipping it costs a handful of games and removes the one claim I could not defend.

A negation guard is in there too. It matches zero entries today. It exists because the next catalogue import might contain "not available on mobile", a sentence containing every word the accept rule looks for, and shipping fullTouchControl off the back of it would be a false accessibility claim — the one kind of error in that file that hurts a person rather than a ranking.

Why an incomplete answer is safe here, when an incomplete device flag is not. accessibilityControl is a positive claim. Saying a game is fully keyboard-controllable does not say it lacks touch. Missing data degrades to silence rather than to a lie. A boolean mobileReady has no such property — it is forced to answer, so it answers wrongly 118 times out of 182. That asymmetry is the whole reason a partial answer can be published at all.

We know this from experience, not theory. Our own entry for Basket Random (RHM Interactive) lists only keys — but the publisher's own public page documents Virtual Buttons: Jump and Throw (Mobile), a line our copy dropped. fullKeyboardControl on that game is still true. A mobileReady: false would have been false. We published a correction for that one two days ago and it is why the rule is shaped this way.

If you make browser games, five things

1. Name the device in the first line of your controls. Not "Move with WASD" — "Keyboard: move with WASD". Portals copy your prose verbatim into their How to Play field, and prose is the only channel that reliably survives the trip. 83 of 190 games in this study lost the information right here, at the source.

2. Put accessibilityControl on your own game page. Four lines, and yours becomes one of the few game pages on the web that answers the question in a form a machine can read:

{
  "@context": "https://schema.org",
  "@type": "VideoGame",
  "name": "Your Game",
  "accessibilityControl": ["fullKeyboardControl", "fullMouseControl"]
}

Only claim an input that genuinely drives the whole game. If a player needs both hands on two devices, say both — and if neither alone is enough, the honest move is the same one we made: say nothing.

3. Tick the boxes on the platforms that have them. itch.io's Inputs field takes about four seconds and puts your game into a filter that 90% of HTML5 games on the site are absent from. That is a discovery surface with almost no competition on it.

4. Write it into your submission text as well as your metadata form. Structured fields do not always propagate between platforms — the partner export our own catalogue is built from carries no developer field at all, which is why studio credits had to be read out of each game's public page one at a time. Prose propagates. Redundancy is the point.

5. Test it the way a stranger will. Unplug the keyboard and try to reach the main menu. Open it on a phone and see whether anything responds to a tap. Whatever you learn is more than any portal currently knows about your game.

Honest limits

Everything here counts documentation, not behaviour. No game was tested by playing it, and none is described as working or broken.
200 pages is a real sample, but three of the four portals contributed three pages each. Playgama at 191 pages is the deep result; CrazyGames, Poki, Y8 and itch.io are spot checks, and they are consistent with it rather than proof on their own.
Three portals — Newgrounds, Armor Games, GameDistribution — are unknown, not zero.
The itch.io counts are a live snapshot taken on 7 August 2026 and moved by six games while I was measuring them.
The 96 pages we now annotate are staged in our build, not yet live. slowden.com is deployed by hand and this ships on the next one. The claim "96 pages emit it" is verified against the generated files; the live site at the time of writing carries 0.
No keyword-demand tool is connected here, so nothing in this article says anything about search volume for any of it.

Where to go next

If you have a browser game finished, or nearly, submit it to SlowDen — it takes a form and a link, and a person reads every one. If you would rather have a constraint to build against, the current Slow Cook round closes on 31 August 2026: pick a challenge, build something small around it, and send it in. Selected entries may get a shoutout on SlowDen's social accounts and a chance to be featured. Nothing is guaranteed, and that is the honest version.

And when you write the page for it, tell people what to hold.

Top comments (1)

Mike Viewfy • Aug 8

Whatever fills those 96 fields only counts if the value is a term a parser recognizes. accessibilityControl expects the WebSchemas vocabulary (fullKeyboardControl, fullMouseControl, fullTouchControl, fullSwitchControl), so "keyboard" or "Arrow keys to move" validates fine as JSON-LD and matches nothing downstream.

I'd keep the supplier's raw control text in its own non-schema field and emit only the mapped term, with the mapping checked in as a table rather than a regex chain. Otherwise the next time an input taxonomy grows you're rereading prose instead of adding a row, and you lose the trail for why a given page got fullTouchControl.

DEV Community