Our first community code contribution made Code on the Go speak

Share This Post

Early in 2026, a pull request arrived in our GitHub repo out of nowhere. No prior discussion, no feature request filed, no “Hey, would you accept a patch for this?” It just showed up. A user had forked our project, made a branch, and started committing.

This became PR #888, from GitHub user makhlwf, self-described as “the ADHD guy who never completed something.”

Well, they completed something.

Why this matters for phone-based development

Makhlwf is visually impaired and had been using Code on the Go (CoGo™) to write software on their phone. They ran into a problem we had not considered: when you navigate a mobile app using Android’s TalkBack screen reader, every button and icon needs a text label. Otherwise, TalkBack just says “button, unlabeled,” which is a lot like being in a hallway with dozens of identical unmarked doors and no idea what’s behind them. Our main editor toolbar was full of those unlabeled buttons.

For a visually impaired developer, TalkBack is the primary navigation tool. If the labels are missing, the IDE is not usable. Makhlwf noticed what was broken, and fixed it.

I love open source!

How the fix works

The foundation of CoGo’s Git UI is JGit, a pure Java implementation of Git. Using JGit gives you responsiveness that a terminal wrapper cannot match.

The mechanism behind TalkBack is elegantly simple. Android has an attribute called contentDescription that you can attach to any UI element. When TalkBack focuses on that element, it reads the description aloud with no custom audio code and no text-to-speech engine to configure. You give each element a label, and the OS does the rest. Our toolbar icons were ImageButton views without content descriptions, so we extended the addMenuItem() function to pass a hint string and assign it: contentDescription = hint.

The smarter part was how those hints get chosen. We wrote a function getToolbarContentDescription() that maps each action’s ID to a localized string resource (“Sync project,” “Start debugger,” “Undo,” “Redo,” “Save,” etc.), all of which are translatable, so TalkBack speaks in whatever language the user has set on their device.

One detail worth highlighting

The Run button (the green triangle at the left end of the toolbar) is context-aware. When no build is running, TalkBack announces “Quick run.” The moment a build kicks off, the same button announces “Cancel build” instead. 

That matters because while a sighted user can glance at a spinning progress indicator, a vision-impaired user needs the button itself to say what it currently does. Getting that right means updating the label to reflect the button’s actual state in real time, not just its default state. That is what accessibility looks like in practice.

Other improvements in the same commit

The pull request picked up several related fixes alongside the toolbar labels. Diagnostic icons (the small markers that flag errors and warnings in your code) now announce “Error” or “Warning” to the screen reader. The navigation drawer lets you know when it opens and closes. And decorative icons next to labeled buttons that add visual flair but no real information are now explicitly marked as “unimportant for accessibility,” so TalkBack skips them and reads the button label instead. (A screen reader describing a decorative icon before providing the meaningful label makes the experience worse for the user trying to navigate.)

What this contribution represents

Because Android’s accessibility framework is already well-designed and does the heavy lifting, this project didn’t require makhlwf to reinvent anything from scratch. What it required is care: someone thinking about the experience of navigating an app without being able to see it and going through the UI element by element to make sure each one says something meaningful.

This is our first merged community pull request, and we could not have asked for a better one. It is a reminder that our users are people who need these tools, and need them enough to improve them. We are grateful to makhlwf for seeing something that needed doing, and doing it.

If you are using CoGo with TalkBack, we would love to hear about your experience, too. And if you build something that adds new capabilities or just works better, smash that New pull request button.  Happy coding!