It would be nice if curses programs all had a standard keymapping or signal that would invoke one of curses screen dump functions. Lacking that, a screenreader would have to jump through a lot of hoops to even know what's on the screen. I suppose you could use tmux instead...it seems to be able to dump the current screen. Either way, still a lot of work to do after you have the raw data.

You don't need to dump the screen, the screen reader takes care of letting you explore the screen by line, word, character, etc.

Some curses programs work reasonably well with screen readers (e.g. Mutt and WeeChat). One useful way to make them more accessible is to put the hardware cursor somewhere useful, even if hidden. Mutt puts it on the same line as the currently-selected message, and if braille_friendly is set, onto the first line of message content when opening one.

WeeChat puts it on the input line. Where this goes wrong is when trying to use fset, where I have no way to move it to the list of options.

> One useful way to make them more accessible is to put the hardware cursor somewhere useful, even if hidden.

You should be doing this anyway to account for hardware terminals where the cursor is always visible, including the traditional VGA/VESA text console that still gets used by default on PC hardware.

Can you give any more guidance on what might constitute "somewhere useful"?

Is the hardware cursor position the default place to start reading from?

Somewhere useful depends on the app. In an editor, it's the line of text I'm editing. In a file manager, it's the currently focused file.

The hardware cursor is where it will start reading when I press read current line, word, etc.

That makes sense. It's a little harder to determine where it should go for something like a chat client where the UI changes asynchronously.

I have met some blind users who were using terminal-based IRC clients. I believe they were using the scripting interface to assist in integrating it with their input/output hardware.