A Barrier That Had Quietly Excluded a Generation
Block-based coding became the on-ramp to computer science for a generation of children because it turned syntax into something you could drag, snap, and see. That visual metaphor is also why it locked out students who cannot see the blocks. For years, a pupil using a screen reader or a refreshable braille display could sit in the same coding lesson as classmates and still be unable to reach the same tool. The update Microsoft MakeCode shipped on July 15 closes that gap by making the block canvas navigable through the assistive technology these students already use every day.
The reach is concrete. The partners estimate 41,506 children and young people with vision loss or impairment across the UK could benefit, a figure specific enough to signal that this was scoped as a population problem rather than a demo. The work came out of a partnership between Microsoft MakeCode, the Micro:bit Educational Foundation, and the Blockly team at the Raspberry Pi Foundation. What makes it credible is where the engineering sits. The teams did not build a separate accessible app off to the side. They made the mainstream tool work for everyone who was already meant to be in the room.
Independence Is the Metric That Matters
The clearest measure of the change came from a student rather than a spec sheet. Zac Herbert, a 14-year-old pupil at New Worcester College, described the difference plainly: it is great to have something you have done yourself, without having to rely on another person to help you do it. That sentence captures the outcome that accessibility work exists to produce. The prior workaround for a blind student in a coding class was a human intermediary reading and moving blocks on their behalf, which is assistance that also removes authorship.
Lucy Gill, head of product at the Micro:bit Educational Foundation, framed the goal as giving many more children the opportunity to learn, create, and build confidence through computing. We would put a sharper point on it. Independence in a learning tool is not a courtesy. It is the difference between a student who produces work and a student who watches work happen. For a subject that feeds directly into the technical workforce, an on-ramp that requires a helper is an on-ramp that leaks talent before it ever reaches a keyboard.
Co-Design Is Why This One Is Likely to Stick
The feature was co-designed with blind and low-vision children and young adults aged 8 to 18, working alongside teachers and accessibility specialists, with input gathered across the UK, Europe, and the United States. That process detail is easy to skim past and central to whether the result holds up in a classroom. Accessibility features built by sighted engineers guessing at needs tend to satisfy a checklist and fail in practice. Features built with the people who will navigate them tend to survive contact with a real Tuesday-morning lesson.
This is the standard we would ask any vendor to meet before claiming an inclusive product. Show the co-design. Name the age range of the testers. Describe how a screen reader and a braille display move through the interface, not merely that the interface is compliant with a standard. The MakeCode work clears that bar, and in doing so it sets a reference point that procurement teams can hold competing coding platforms against. Compliance language is cheap. Evidence that disabled learners shaped the build is the signal worth paying for.
The Leverage Is in Blockly, Not Just MakeCode
The most strategically important fact is that the accessibility lives in Blockly, the open-source engine that powers a large share of the world's block-coding tools. Because the improvement sits at the engine layer, its benefit does not stop at MakeCode for the micro:bit. Any platform built on Blockly can inherit the same screen-reader navigation, which means a single well-executed piece of engineering can propagate across products used by tens of millions of learners. That is the difference between fixing one app and shifting a category.
For technology leaders, this is a familiar and useful pattern. When a capability is solved in a shared dependency, it compounds. The organizations describe the change as a step toward making mainstream coding tools accessible for future generations, and the mechanism behind that ambition is precisely the open, shared nature of the underlying library. It is worth noting how rarely accessibility gets this kind of leverage. Most inclusive features are trapped inside a single vendor's product. Solving it in Blockly turns one team's investment into an industry-wide default.
Why This Belongs in a Procurement Conversation
Districts and universities buy coding curricula and hardware kits every year, and accessibility usually enters the conversation late, as a compliance question raised by a legal team rather than a design question raised by an instructional one. The MakeCode release is a reason to move it earlier. When an engine-level solution exists and is free to adopt, a vendor that ships a block-coding product without screen-reader support is making a choice, and buyers are entitled to ask why. The existence of a reference implementation removes the excuse that inclusive coding is too hard to build.
There is a workforce argument underneath the equity one. Organizations across every sector say they cannot find enough technical talent, and they simultaneously tolerate learning tools that exclude students with disabilities at the earliest stage of the pipeline. Those two positions are hard to reconcile. Widening who can author code in primary and secondary school is one of the few interventions that expands the eventual talent pool without lowering any bar. For CIOs who fund early computer-science programs, insisting on engine-level accessibility is both the right call and a rational investment in future hiring.
A Model for Accessible AI Tools Next
The timing invites a comparison. As AI tutors and code assistants flood classrooms, most arrive with the same blind spot that block coding had for a decade, an interface designed for sighted users with accessibility promised later. The MakeCode work shows the alternative is achievable when teams commit to it early, co-design with disabled users, and place the fix in a shared layer so the benefit scales. That playbook translates directly to the AI education tools now competing for district budgets.
We would encourage buyers to carry this expectation into every AI procurement this year. Ask how a tutoring assistant behaves under a screen reader. Ask whether its outputs are navigable with a braille display. Ask whether disabled learners were in the design loop. The block-coding community has just demonstrated that these are answerable questions with concrete engineering behind them. Accessibility is not a constraint that slows a product down. On the evidence of this release, it is a discipline that makes a tool genuinely usable by everyone it claims to serve.
