Week 11 Session: Accessibility

What happens when the button only confirms, and something else keeps time

3 May 2027

Every week so far has read timing that the player controls. Scanning inverts that: an external cursor cycles through options at a fixed cadence, and the button’s only job is to confirm when it’s on the right one. This is week 7’s mode-dependent meaning again — but now the “mode” is decided by an automatic clock instead of the player, which is the same shape as week 4’s rhythm run in reverse. It’s also how real single-switch assistive-access interfaces work, not an invented constraint for this course.

Before the session#

Bring a prototype that uses sequence or movement — you’ll be replacing its timing model, not its content.

In the session#

Demo of a working scanning-cursor prototype, then build time adapting your own, followed by playtesting each other’s under a constraint (reduced reaction time, or looking away from the screen).

Studio exercise#

Adapt an earlier prototype to be playable through an auto-scanning cursor plus a single confirm press. Play it under a real constraint yourself, and write down — specifically, not generally — what broke and why.

By the end#

You understand that this semester’s one-button constraint is not a game-jam gimmick: it’s the literal access method some real users have to any software at all, not only games.