Code Up

GUI

Inspiration

When I was a kid, I wanted glasses because I thought they looked cool.

Then I actually needed glasses.

Turns out having your vision depend on a piece of glass sitting on your face is significantly less fun when it is real. Obviously, that is nowhere close to being visually impaired, but it was probably the first time I thought about how much of everyday life quietly assumes that you can see.

A few years later, I visited a home for people with disabilities in Patiala. I was talking to a visually impaired kid there when he asked me what my dream was.

I had no answer.

That bothered me for a long time. Here was someone who had been given fewer opportunities than me and still had something he wanted to become. I had a computer, the internet, school, and the freedom to learn almost anything, yet I had never really asked myself what I wanted to do with any of it.

Eventually, that conversation pulled me toward accessibility.

I already loved programming, so I started questioning something I had never thought about before: almost every beginner coding tool assumes you can see it.

You are expected to notice indentation, scan through a file, spot a red underline, follow a traceback with your eyes, and watch values change on a screen.

So I started building CodeUp around a different question:

What would learning to code feel like if sight was never assumed in the first place?

What I built

CodeUp is a blind-first Python learning environment where beginners can write, run, debug, and understand code through speech, sound, and keyboard interaction.

Instead of simply reading an ordinary IDE aloud, I tried to rethink parts of programming that are usually visual.

Code structure can become an Audio Code Map. Indentation can have sound. Execution can be narrated step by step. Variable changes can be spoken. Errors can be explained as a journey through the program. Changes between two versions of code can be replayed through audio.

The goal is to give a blind beginner somewhere to start before they are expected to master a professional IDE and a complicated screen-reader workflow.

And it has already left my laptop.

I have piloted CodeUp with 10 visually impaired students, demonstrated it with NAB Delhi, and had it tested and reviewed by accessibility and visual-impairment organizations across India.

Those sessions have probably shaped CodeUp more than anything I could have designed alone.

How I built it

I built CodeUp mainly with Python, Flask, JavaScript, HTML, and CSS, with Python's AST helping me understand the structure of a student's program.

A lot of the features came from turning visual programming concepts into questions.

How do you "glance" through a file without seeing it?

How do you notice that one line changed?

How do you understand where you are inside nested Python blocks?

Those questions became features like Audio Code Maps, Mistake Replay, indentation sonification, Variable Watch, narrated execution, and conditional audio breakpoints.

Challenges and what I learned

The hardest lesson was that making something technically accessible does not automatically make it pleasant to use.

During testing, CodeUp's own speech sometimes collided with NVDA. A prompt could be announced correctly while keyboard focus went somewhere useless. Long output could get cut off. Page structure that looked completely normal to me could become confusing through a screen reader.

Real testing made those problems impossible to ignore.

It also taught me that I cannot build accessibility entirely from my own desk. Every time someone actually uses CodeUp, they find an assumption I did not realize I was still making.

That is probably the most important thing CodeUp has taught me.

I started it because I wanted to remove one assumption from programming: that the person learning it can see.