quest'n'click 4.5.0 · r1

Built for quest'n'click 4.5.0, revision r1. Whether it is published, and which one is current, is recorded at publication.json.

Accessibility

Français · Type: reference + explanation · Audience: player · Context: player's browser · Status: ready · Applies from: 4.3.0

The player (DOM painter) · contract: stable · verified by CI (support matrix of 4.4.0, 2026-10-23): Chromium on the desktop, mouse and keyboard; Chromium and WebKit at a phone's size, touch and keyboard (emulated); axe-core on every screen (not a WCAG claim) · automated checks: jobs e2e; CI plan e2e; 2 test files · people's passes: phone-both-renderers not run (#83), code-wheel-human not run (#78), blind-playtesters not run (#76) · known limits: no-screen-reader-pass

What a quest'n'click game offers a player who uses the keyboard, a screen reader, larger text or less motion; what is checked by machines, what only people can check, and where those checks stand. True from 4.3.0 (verb keys and their announcement); the rest is older and says since when.

What the engine does

Every game made with the engine gets these, without its author writing anything:

Text, motion, sound and colour

What is checked, and what is not

By machines, in CI, on every change that can affect the player:

What the engine can claim is therefore "tested at the keyboard, no serious or critical axe violation on the screens checked". It is not a WCAG conformance claim.

Limit · no-screen-reader-pass No person has played a quest'n'click game with a screen reader for a release yet. The checklist exists (docs/dev/SCREEN-READER.md: VoiceOver on iOS or TalkBack on Android, the title, a room, an action, an item, a conversation, the map, the pause menu, a minigame, the ending), and the support matrix lists a VoiceOver or NVDA pass under "checked by people (not yet done)". As of 4.4.0, the people's passes that read this surface, phone-both-renderers (#83), code-wheel-human (#78, the code wheel's text alternative by a screen-reader user) and blind-playtesters (#76), are not run.

Accessibility and fair play in speedruns

A speedrun category declares the inputs it allows (mouse, touch, keyboard, gamepad, macros). An accessibility option is never an implicit cheat: the text speed, the text size, reduced motion and the readable font change nothing in the in-game time (a line costs the same logical time at every speed), and the keyboard's and the screen reader's targets are the same actions as a tap. A category that forbids an input says so; the inputs a run used are declared by the player's browser (its word, as the real-time clock is). See Speedrun for players and, for authors, Speedrun for authors.

Report a barrier

A barrier is a bug. Open an issue on the project's tracker with the screen, your device, browser and assistive technology, and what you heard or could not reach. A session file (pause menu › Save › Export session) helps the author replay what you did.

References


Edit the source of this page · Report an error