Accessibility adaptation
The week 11 checkpoint — an earlier prototype adapted to scanning input, with an honest account of what broke
Take a prototype built for direct, player-timed input, and make it work for someone whose only input is a single, well-timed confirm.
The adaptation doesn’t need to be elegant — it needs to work, and the account of what didn’t survive the change needs to be specific enough that someone who hasn’t seen your prototype could still learn something from it.
What you submit#
The adapted prototype, and a written account (no fixed length, but vague answers like “it was harder to play” will be marked down) of exactly what broke and what you changed to fix or accept it.
The spec
The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.
- an earlier prototype is adapted to run through an automatic scanning cursor and a single confirm press
- a written account names specific things that broke in the adaptation, not general impressions
How it is marked
| Criterion | Weight |
|---|---|
| The adaptation is actually playable via a scanning cursor | 50% |
| Specificity and honesty of the written account | 50% |