Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Review accessibility of [small canvas puzzle or diagram tool]. List the essential state, actions, instructions, and feedback a user needs to complete its main task. Keep that model separate from the drawing commands. Provide an appropriate semantic interface or equivalent interaction path for the supported experience rather than assuming painted labels are accessible controls.
Support [keyboard actions and meaningful status updates] with a visible focus strategy. Keep canvas input, alternative controls, and the underlying state synchronized through the same actions. Avoid announcing every animation frame; announce meaningful changes at an appropriate pace.
Verify the task without pointer precision, with the canvas unavailable where a fallback is intended, and with a controlled failure or restart. Check that both interaction paths produce the same accepted state. Report manual and assistive-technology evidence, plus limitations of the chosen alternative.Make this prompt yours
An image description alone rarely exposes the full interaction of a game. Keep the alternative appropriate to the actual task.
You might also hear
- canvas accessibility
- keyboard puzzle
- semantic alternative
- drawing controls
- status announcements
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original canvas interaction review. MDN confirms drawn pixels do not expose semantic controls; synchronized alternative actions and meaningful announcements are requirements to verify, not an accessibility certification.