When contributing to open-source software, writing code is only half the process — the other half is testing it with real users and listening to feedback. This becomes especially crucial in accessibility software like NVDA (NonVisual Desktop Access), where your “audience” might be using screen readers in ways that are totally invisible to sighted developers.
Through contributing to NVDA, I learned that good code doesn’t just compile — it communicates, behaves predictably, and respects user workflows. To make that happen, you need user testing, active dialogue, and a feedback loop that doesn’t end when you click “submit pull request.”
How I Tested My Contribution
For my first contribution, I worked on an issue related to NVDA’s Settings dialog: when users press Alt+A (Apply), the focus would jump to the “Categories list”, which was confusing. The fix involved keeping the focus on the Apply button and notifying the user that their settings were applied.
But I couldn’t just test this visually — NVDA is made for screen reader users. So I had to step into the user’s world.
I used NVDA’s Python Console, debug logs, and speech output to validate behavior. I opened the Speech Viewer (under NVDA menu → Tools) to see what NVDA was saying after my changes. This helped ensure the feedback message (“Settings successfully applied”) was being spoken, and that the focus didn’t shift unexpectedly.
I also followed NVDA’s internal guidelines, like using ui.message() for accessibility-compliant output and avoiding visual-only cues like wx.TipWindow. These weren’t just coding standards — they were community wisdom about what works best for blind users.
Getting Community Feedback
After testing locally, I submitted a pull request and quickly received thoughtful review from one of NVDA’s core maintainers. They pointed out:
- My use of
wx.TipWindowdidn’t provide audio feedback - The string I used wasn’t translatable (important for international users)
- I was using a 3-second timeout, which could be inaccessible for slower users
This feedback wasn’t just about fixing bugs — it was a demonstration of true inclusive design. I replaced my window with ui.message(), used core.callLater(500, ...) for timing consistency, and marked strings for translation with _() and developer comments.
The dialogue was public and collaborative. GitHub’s code suggestions, inline comments, and pull request history made it easy to refine my work without starting over. This was a great example of asynchronous collaboration — reviewers in different time zones, reviewing at their own pace, but building toward shared quality.
How to Communicate While Still Developing
When contributing work-in-progress, communication is key. While the NVDA has a discord channel is was not very active. Most conversations actually takes place on GitHub! However, I’m sure the situation varies from project to project. Here’s what worked for me:
- Be clear in PR titles: it should provide enought information to understand the purpose of the PR just by reading its title.
- Leave clear commit messages: Every change had a reason, not just “fix stuff.”
- Ask questions directly in issue threads if something was unclear.
- Always explain your approach, not just in the PR description, but also during early stage discussion and post-dev revision.
Maintainers appreciate context. They’re busy, and knowing why you made a choice helps them give faster, more useful feedback.
Future Testing Strategies
If I continue working with NVDA or similar projects, I plan to deepen my testing with:
- Portable builds of NVDA to test changes outside the dev environment
- Using NVDA’s speech history (NVDA+Numpad 1) for review
- Screen reader-only workflows to simulate how blind users really experience dialogs
- Issue templating and labeling to clarify what’s being fixed, how it’s tested, and who it affects
In larger projects, testing can also include unit tests, automated UI testing (e.g., using tools like Appium), and user surveys — though NVDA mostly relies on live testing and community feedback.
Final Thoughts
Working on NVDA taught me that the user is always part of the development process. You don’t just write code for users — you write it with them in mind, and sometimes with their voices guiding you directly.
Open-source makes that feedback loop faster and more public, which can be intimidating at first — but it’s also what makes your code better, more ethical, and more human.
Leave a Reply