NVDA: the open source Windows screen reader, from install to first use

Who NVDA is for, and the problem it removes

NVDA (NonVisual Desktop Access) is a screen reader for Microsoft Windows that speaks what is on screen and lets a blind or low-vision user drive the operating system by keyboard. The README states it is developed by NV Access in collaboration with a global community of contributors. That sentence carries more weight than it looks: the alternative for most Windows users is a commercial screen reader, and the cost of that licence is the barrier NVDA exists to remove. It is free, and the source is public.

The audience is not only end users. The repository ships projectDocs, a contributing guide, a code of conduct and a roadmap, which tells you the project expects translators, testers, add-on authors and code contributors as first-class participants. If you write software that has to be usable without sight on Windows, NVDA is also the thing you test against. The pyproject.toml classifier lists Development Status 5 - Production/Stable and Intended Audience End Users/Desktop, so this is not a research prototype.

One boundary is set in the same file: the only operating system classifier is Microsoft Windows. There is no macOS or Linux target.

How the Python codebase is put together

The runtime is Python, and the dependency list in pyproject.toml tells you the shape of the machine. wxPython 4.2.4 supplies the GUI layer. comtypes and pywin32 are the Windows COM and Win32 bindings, which is how NVDA reaches into native controls and the accessibility APIs underneath them. pycaw is described in the file as a Core Audio Windows Library used for sound split, so audio routing is handled in-process rather than by an external mixer. bleak 3.0.2 covers Bluetooth, pyserial 3.5 covers serial devices.

The repository layout confirms a split between Python and native code. There is a source/ tree, an nvdaHelper/ directory for the native helper component, and a launcher/ directory. The presence of rpyc 6.0.2, annotated in pyproject.toml as the NVDA bridge for 32 bit shim, tells you NVDA runs a bridge so that 32-bit processes can still be inspected from the main process. That is a real architectural constraint of Windows accessibility work, not an implementation detail you can ignore.

Speech and braille are not vendored as dependencies. Instead the project ships an add-on system, and the README links the add-ons manager section of the user guide for getting them. In practice this means the core stays lean and synthesiser support arrives through add-ons. The trade-off is that a fresh install may not speak with the voice you want until you add something.

Installing NVDA and reading your first window

The README does not carry install instructions. It says: to learn more about NVDA or download a copy, visit the main NV Access website. So the download comes from nvaccess.org, and the steps below assume you have the installer from there. What the repository does give you is the developer path, which is where a contributor or an add-on author starts.

The pinned interpreter range is the first thing to check. The pyproject.toml requires-python field is >=3.13,<3.14, and the repository carries a .python-versions file and an ensureuv.ps1 script, which suggests uv is the expected way to provision that interpreter. Clone the repository, then run the build through scons:

git clone https://github.com/nvaccess/nvda.git
cd nvda
scons source

The sconstruct file at the repository root is the build definition, and scons.bat is the Windows entry point. After a successful build, runnvda.bat launches the built copy from the source tree, which is how you test a change without producing an installer.

For a change you intend to submit, the repository provides separate check scripts rather than one aggregate command. runlint.bat runs the linter, rununittests.bat runs the unit tests, and runsystemtests.bat runs the system tests. There is also runcheckpot.bat, which relates to translation string extraction, and runlicensecheck.bat for licence headers. If you only run the unit tests you have not run the checks the project actually gates on.

Once NVDA is running, the everyday mechanism is browse mode, which the search questions name directly. In browse mode the arrow keys move through a document or web page by element rather than by raw keystroke, and NVDA announces headings, links and form fields as you pass them. That is the mode most users spend their time in when reading.

Where NVDA is the wrong tool

The clearest limitation is platform. The pyproject.toml classifier list contains exactly one operating system entry, Microsoft Windows. If you are looking for a screen reader on macOS or Linux, NVDA does not ship one, and the README does not offer a port or a workaround. Search interest in NVDA for Mac exists, but the repository does not answer it.

A second limitation is the Python version pin. requires-python is >=3.13,<3.14, an unusually narrow window that excludes both 3.12 and 3.14. Anyone building from source on a machine with a different interpreter will fail before reaching the interesting problems. The presence of .python-versions and ensureuv.ps1 is the project's answer, but it means you adopt the project's toolchain rather than your own.

The third is the licence. The README describes NVDA as available under a modified GNU General Public License version 2 or later, and points to copying.txt for the details. Modified is the operative word. If your plan depends on the exact obligations of stock GPLv2, you need to read that file; the README does not summarise what was changed, and this article cannot either.

Finally, building from source is not the normal path for a user. The repository's own instructions route end users to nvaccess.org for a download. Treating the git checkout as the install method adds a compiler, scons and a specific Python version to a task that otherwise needs none of them.

NVDA against a commercial screen reader, and against Narrator

The real alternative on Windows is a commercial screen reader, and the difference is not only price. A commercial product typically ships a vendor support contract, a curated set of application scripts maintained by the vendor, and a single accountable party when something breaks in a specific program. NVDA replaces that with a community: the README points to a contact list of NV Access and community experts, an issue tracker with its own readme, and a contributing guide covering triage and testing. Support exists, but it is distributed and best-effort, and the quality of any given application script depends on whether someone in the community uses that application.

Microsoft Narrator is the other comparison, and the difference in approach is architectural. Narrator is part of Windows and updates with the operating system. NVDA is a separate application with its own release cadence, visible in the release list: 2026.2 shipped on 2026-08-31, with 2026.3beta1 on 2026-09-07 and 2026.3beta2 on 2026-09-14. That cadence means you can be on a stable release, a beta, or an alpha build, and the README exposes separate status checks for alpha and beta builds on master and the beta branch. Narrator gives you no such choice. NVDA gives you the choice and the responsibility that comes with it.

The add-on model is the third axis. Where a commercial reader bundles its support, NVDA keeps synthesisers and extra functionality outside the core and installs them through the add-ons manager. You gain the ability to add only what you need. You lose the guarantee that everything works together, because the combinations are assembled by users.

Maintenance, releases and what the licence asks of you

The repository is not archived, and the last push was on 2026-09-22, so development is current. The release naming is date-based: 2026.2 is the stable release from 2026-08-31, and 2026.3beta2 from 2026-09-14 is the newest beta. There is no long-term support branch mentioned in the README, so the upgrade path is forward through the numbered releases. The README does not document rollback, and it does not describe how long a given release receives fixes.

For a contributor, the upgrade cost is concentrated in the toolchain. The Python window moves with each cycle, and the dependency list is fully pinned: wxPython==4.2.4, comtypes==1.4.16, cryptography==50.0.0, pywin32==312, and so on. Every one of those pins is a decision the project has already made for you, and bumping any of them is a change to NVDA, not a local preference. The configobj entry is annotated as pinned to a commit in tool.uv.sources, which means at least one dependency is tracked by revision rather than by version number.

On licensing, the README states a modified GPLv2 or later and points to copying.txt. The pyproject.toml classifier says GNU General Public License v2 or later (GPLv2+). Those two statements are consistent in direction but the word modified is doing real work, and the README does not explain it. If you intend to redistribute NVDA, bundle it, or link it into a product, read copying.txt and get your own advice. Nothing here is legal advice.

One more maintenance signal worth knowing: the build pipeline runs CodeQL security analysis on master, and the repository carries a security.md. That is a project that expects to be audited.

Editorial conclusion

Adopt NVDA if you need a Windows screen reader you can inspect, script and extend, and if you accept the GPLv2+ licence terms that come with that. Do not adopt it if you need macOS or Linux support, since the pyproject.toml classifier is Microsoft Windows only. Before committing, verify that your Python toolchain matches the >=3.13,<3.14 range pinned in pyproject.toml, and read copying.txt rather than assuming the licence is plain GPLv2.

Frequently asked questions

Official sources

1. Issues
2. nvaccess/nvda on GitHub
3. Project website
4. README
5. Releases