Accessibility

This page focuses on how to adapt the experience without losing what makes it work. The priority is not to create a different lesson for every student. The priority is to keep the pathway readable, flexible, and recoverable so more learners can participate meaningfully.

What to Adapt First

When changes are needed for access, pacing, or confidence, the learning conditions should change before the content does.

  • shorten the amount of new information students need to process at one time
  • keep the skillmap sequence intact so learners still move through Garage, On the Road, and Finish Line in order
  • reduce the number of decisions students make at once before reducing the challenge level itself
  • use one clear prediction, one visible test, and one short explanation as the core learning cycle

In most cases, it is better to simplify the pace, the role structure, or the amount of discussion than to remove the central mechanic students are meant to understand.

MakeCode Arcade Supports You Can Use

MakeCode Arcade already gives educators several built-in supports that make adaptation easier.

  • the guided tutorial format breaks work into smaller steps instead of presenting a full project all at once
  • the Blocks workspace helps learners focus on cause and effect without needing to manage spelling or punctuation first
  • learners can use keyboard, touch, or supported controller input depending on the device setup
  • the simulator gives immediate feedback, which helps students test a change without waiting for teacher confirmation
  • the browser-based experience works with common device and browser supports such as zoom and platform accessibility settings
  • the project can be experienced without sign-in for the core lesson, which reduces one common launch barrier

These supports do not remove the need for facilitation, but they do give you a strong starting point for accessibility and differentiation.

Adaptations for Pacing and Cognitive Load

These moves work well when students need a slower on-ramp, more repetition, or less information at once.

  • keep directions to one action at a time and point to one block, value, or mechanic before moving on
  • pause after each first success, such as car movement, the first shakedown, or the first obstacle interaction
  • treat the built-in tutorial hints as part of normal problem solving, not as a sign that a learner is behind
  • replace long verbal explanations with short prompts such as “Change one value,” “Test it,” or “What changed?”
  • use the Garage Shakedown and later replay moments as structured chances to stop, reset, and try again

Adaptations for Shared Devices and Participation

This project works well with shared-device play when roles are explicit and useful.

  • use a Driver role for controls and a Navigator role for reading, prediction, and explanation
  • rotate roles at natural checkpoints such as the end of a shakedown, a pit stop decision, or a replay
  • if a third learner joins, assign a Reporter role to track what changed and what the team noticed
  • keep role language visible on the board or projector so transitions do not depend on memory
  • use short sentence starters when learners need support with reflection, such as “We changed…”, “We noticed…”, or “Next time we would…”

Adaptations for Learners Who Need More Support

These moves work well for learners who are new to coding, hesitant to participate, or easily overloaded.

  • preselect one or two vocabulary terms to teach directly instead of front-loading the full definitions list
  • preview the purpose of a stage before students build, for example “In this part, we test whether a faster car creates a new cost”
  • narrow remixing to one safe change, such as one variable or one reward rule, instead of offering open-ended choices first
  • invite students to predict with gestures, quick partner talk, or a single sentence if writing would slow them down
  • allow learners to stay in Blocks rather than switching representations unless there is a clear instructional reason

Adaptations for Learners Who Need More Challenge

Differentiation also means making room for students who reach understanding quickly and need a stronger stretch.

  • ask them to change two connected values and explain the tradeoff they created
  • have them compare two runs and defend which version feels more balanced, fair, or strategic
  • invite them to improve clarity for another player by revising a message, score display, or reflection prompt
  • ask them to connect a code change to a specific role such as strategist, telemetry analyst, or software engineer
  • point them to the Supplementals page when you want a fuller set of remix and extension pathways

Multiple Cues and Readability

Important game events should be understandable in more than one way.

  • use motion, score, text, and sound together when possible
  • avoid relying on color alone to show success, risk, or urgency
  • make state changes clear enough that a student can explain what happened from gameplay evidence, not just from teacher narration
  • keep celebration and warning feedback distinct so students do not have to guess what a signal means
  • confirm that important HUD elements and tutorial text are readable on the actual projector and learner devices you plan to use

If readability falls short in the room, the fastest recovery is usually to simplify the shared reference point rather than stopping the session entirely.

  • shift attention to one score lens or one mechanic at a time instead of trying to read every HUD element aloud
  • move learners into pairs around a readable device if the projector view is unreliable
  • narrate one key result verbally, then send teams back to testing instead of lingering on a hard-to-read summary screen
  • deprioritize any screen or prompt that depends on fine text and keep the session anchored in movement, outcomes, and one short reflection question

Belonging and Confidence

Accessibility is not only about technical access. It is also about whether students feel that their way of contributing matters.

  • affirm observation, patience, communication, revision, and debugging as real STEM strengths
  • make it clear that prior coding experience is not required to contribute meaningfully
  • avoid framing strong performance as something only the fastest or most confident learners can achieve
  • connect different team roles to different kinds of thinking so more students can see themselves in the work
  • treat mistakes as usable data, especially during testing and reflection

Quick Planning Check

Before the session begins, these are the key questions to check:

  • Can learners access the game with the input method they will actually use?
  • Can the room read the main text, score areas, and prompts from where they are sitting?
  • Can a student understand the next step without a long explanation from the facilitator?
  • Do learners have a clear role if devices need to be shared?
  • Is there a clear fallback if the projector view or HUD text is harder to read than expected?
  • Is there a clear mechanic to simplify first if the room becomes overloaded?
  • Is there a clear stretch prompt to use if a group finishes early?