Viewing Options


Skip navigation Stay up to date and informed on the latest goings on here at Nathan Tech.
Subscribe to our newsletters!

Using the command line with a screen reader

The command line is not inherently inaccessible. In some ways it is wonderfully simple: type a command, press Enter, get text back.

The awkward bit is that the text keeps moving.

A graphical application usually gives you controls you can return to. A terminal gives you a prompt, some output, another prompt, and possibly 400 lines of compiler complaints disappearing enthusiastically towards the top of the window.

The useful skill is therefore not just typing commands. It is learning how to leave the live prompt alone while you review what the terminal has already printed.

This guide uses Windows Terminal, Command Prompt and PowerShell as examples. Exact behaviour can vary with Windows, terminal application and screen-reader version, so treat the keystrokes below as a working method rather than a law of physics.


First: the live cursor and the reading cursor are different things

Suppose the terminal contains:

C:\projects>python --version
Python 3.13.5
C:\projects>

The real input cursor is at the final prompt. That is where your next command will be typed.

You may, however, want to read the line above it without moving that input cursor. This is where the screen reader's review facilities matter.

NVDA calls this its review cursor. JAWS has the JAWS Cursor and can also place a snapshot of a window into its Virtual Viewer.

The principle is the same: inspect old output without accidentally turning your inspection into the next shell command.


A first terminal exercise

Open Command Prompt, PowerShell or Windows Terminal and type:

python --version

If Python is installed and available through PATH, you should hear a version. If it is not, you will hear an error instead. Either result is useful for this exercise.

Now try something with several lines. In Command Prompt:

dir

Or in PowerShell:

Get-ChildItem

Do not worry about understanding every line. The point is to produce enough output that you need to review it.


Reviewing terminal output with NVDA

There is one terminology trap worth clearing up first.

NVDA's browse mode is not normally the thing you use to read a Windows terminal. Browse mode is the virtual-document system you probably know from web pages, where H moves by heading and K moves by link. You can force browse and focus mode with NVDA+Space in applications that support browse mode, but a terminal is primarily reviewed with NVDA's review cursor.

People sometimes call any screen-reader reading cursor a "virtual cursor", so the terms get muddled. In NVDA, the distinction matters.

Desktop keyboard layout

With Num Lock off, the numeric keypad controls the review cursor:

The important part is that moving the review cursor does not normally move the terminal's typing position. You can wander backwards through output, inspect an error and leave the actual command prompt where it was.

Laptop keyboard layout

If you use NVDA's laptop layout, the equivalent review commands use the NVDA key with other keys. NVDA's Input Help is the safest way to learn the exact gestures for your current layout: press NVDA+1, try a key, and NVDA tells you what it does without carrying out the command. Press NVDA+1 again when finished.

This is particularly useful because many long-time NVDA users have customised their keyboard layout.

Finding text in a long console

In modern Windows console support, Control+F can be extremely useful. Search for part of an error message, a filename or simply the word error. On supported Windows Console Host versions, NVDA updates its review position to follow the found text.

That is often quicker than climbing through 600 lines one at a time like an unusually determined goat.

Copying something you found

NVDA can mark and copy text using the review cursor. NVDA+F9 marks the start of a selection. Move the review cursor to the other end, then press NVDA+F10 twice quickly to copy it.

For a one-off compiler error, copying it into Notepad can sometimes be easier than continuing to wrestle with a constantly changing terminal window.


Useful NVDA settings

For terminal work, the setting you are most likely to change is Report dynamic content changes. Leave it on when new output is useful; turn it off temporarily when a build turns speech into soup.

Typing echo, punctuation and braille tethering can also make a large difference. They are covered properly in Screen reader and Windows Terminal settings for development.


Reviewing terminal output with JAWS

JAWS gives you two particularly useful approaches.

The JAWS Cursor

On the desktop keyboard layout, press Numpad Minus to activate the JAWS Cursor.

Freedom Scientific specifically recommends this approach for reviewing Windows Terminal output. Once the JAWS Cursor is active, use the arrow keys to move through text without moving the live PC cursor.

A useful sequence is:

  1. Press Numpad Minus to switch to the JAWS Cursor.
  2. Press Insert+Numpad Minus to route the JAWS Cursor to the PC cursor. This puts your review position at the live command area.
  3. Use Up Arrow to move backwards through previous output.
  4. When finished reviewing, press Numpad Plus to return to the PC Cursor.

In JAWS laptop layout, the default equivalents are Caps Lock+P for the JAWS Cursor and Caps Lock+Semicolon for the PC Cursor.

Virtualize the window

For a large lump of output, this is often even nicer.

Press Alt+Insert+W in desktop layout to Virtualize Window. JAWS takes the current window content and puts it into the Virtual Viewer.

Now you can read it much more like a document. Arrow around, search, select and copy text without worrying about the live terminal underneath.

In laptop layout, the default command is Alt+Caps Lock+W.

This is the JAWS feature that is closest to what many users mean when they say they want a "virtual cursor" for terminal output.

What about Insert+Z?

Insert+Z toggles the JAWS Virtual PC Cursor in applications that support it, particularly web and HTML-style content. It is not the main terminal-review technique described by Freedom Scientific for Windows Terminal.

For the terminal, think JAWS Cursor for moving around the live window and Virtualize Window when you want a document-like snapshot.


Useful JAWS settings

JAWS Quick Settings lets you make application-specific changes without inflicting your terminal preferences on the rest of Windows. Typing echo, punctuation, screen echo and Speech History are all worth knowing about.

See Screen reader and Windows Terminal settings for development for the settings pass.


Make the terminal behave

Windows Terminal has its own accessibility-relevant settings too: scrollback history, input scrolling, bell behaviour and selection/copy options.

Rather than burying those in the middle of this tutorial, they live with the NVDA and JAWS configuration advice in Screen reader and Windows Terminal settings for development.


Exercise: find the useful error in a pile of output

Knowing the review keys is lovely. Knowing what to do when a build has just vomited a traceback over 200 lines is rather more useful.

For a safe exercise, create a file called broken.py containing:

print("before the error")
print(1 / 0)
print("after the error")

Run:

python broken.py

You should get a Python traceback ending in a ZeroDivisionError.

With NVDA

  1. Leave the real terminal caret at the new prompt.
  2. Use the review cursor to move backwards through the traceback.
  3. Find the final exception line.
  4. Move further back and find the line beginning with File. Notice that it contains the filename and source line number.
  5. Use review-copy commands to copy the useful portion if you want to paste it into an editor, search engine or bug report.
  6. Return your attention to the live prompt and run another command. You have inspected the failure without disturbing the command line.

With JAWS

  1. Switch to the JAWS Cursor and route it to the PC cursor.
  2. Move backwards through the traceback until you find the exception and source line.
  3. Return to the PC Cursor when you are ready to type again.
  4. Now run the broken program once more and use Virtualize Window. Find the same error in the Virtual Viewer and try copying it from there.

That is the basic debugging loop you will use constantly: run, hear failure, review backwards, find the first useful location, copy if necessary, return to the prompt.

Now make it noisy

Run a command that produces a longer directory listing or a real build from one of your own projects. Practise finding a distinctive word such as error, failed or a filename.

If automatic speech becomes useless while output is streaming, temporarily reduce it. The objective is not to prove that you can listen to 900 lines at conversational speed. The objective is to find the line that tells you what broke.


Commands that keep updating the screen

Some command-line programs print one result and stop. Others update constantly: package installers, compilers, test runners, download tools and development servers.

You do not have to listen heroically to every line.

With NVDA, turn dynamic content reporting off temporarily if the stream becomes useless, then review the output when the command stops.

With JAWS, reduce automatic echo if necessary and use the JAWS Cursor or Virtualize Window to inspect the useful result afterwards.

Also remember Control+C. In many command-line programs it interrupts the running command. That is useful when you intentionally want to stop something, but slightly less delightful when you thought you were copying text.


Command history is your friend

At a normal shell prompt, Up Arrow usually recalls the previous command and Down Arrow moves forward through command history.

This changes the actual command line. It is not a reading command.

That distinction is why the review cursor matters. If you press Up Arrow while the live terminal has focus, you may retrieve yesterday's enormous build command instead of reading the previous line of output.

If your intention is "read what happened", enter NVDA review, the JAWS Cursor or a virtualized window first.


When the screen reader says nothing

Silence does not automatically mean failure.

Ask a few questions:

Be cautious with that last one if the command is performing an operation that should not be interrupted.


A good working habit

When you are learning, keep the distinction brutally simple:

Once that clicks, the command line stops feeling like an inaccessible stream of disappearing text and starts behaving like what it really is: a text interface with a slightly unusual reading model.


Continue learning

If the commands themselves are still mysterious, continue with Introduction to the Windows command line and Environment variables and PATH.

Official screen-reader references


Back to Developer Central

Return to the Developing with a screen reader learning path.

Back to the top

Thank you for visiting!

Thanks for visiting this page. Please tell your friends about us!

Share Nathan Tech on Twitter/X


This page has been viewed 33 times since November 3rd, 2018.

Why not follow us on Twitter/X: @NathanTech7713


Recently viewed products

Products other visitors have looked at recently:


Nathan Tech

It's not disability

It's ability!

Last updated Saturday 12th April 2025 21:06:37

Copyright © 2013-2026 Nathan Tech. All rights reserved.