vim is outstanding. It holds a lot of potential for blind users. One out-of-the-box problem that surely must have a quick and easy workaround, such as placing a single line in the vimrc, I hope is all that is needed to fix a very serious limitation when using vim with screen readers (tested with both NVDA and System Access): When moving to a line longer than what appears to be a hard-coded maximum width of around eighty characters, there is no reading past that preset width. In other words, vim seems somehow to hide whatever doesn't fit on the screen, and that is where the screen reader stops reading, similar to Microsoft Notepad, in which there are about a thousand characters before a line break is imposed, although with Notepad the line is truly wrapped without inserting any kind of newline sequence (so that the text can be copied and pasted in its original form), and arrowing down in the Notepad window allows reading to continue. With vim, regardless of the combinations of wrap, linebreak, and so on, that I have experimented with, the screen reading simply stops at that maximum line length. The screen reader will actually echo the column position when arrowing through a line (not with the movement commands unfortunately), so that starting from the beginning of the line and arrowing right states position 80 is reached, then counting starts over at 1 for the longer lines. There are two major problems here: The most obvious is that a blind user will have to jump to that last column position, arrow up or down, then back to the long line, which will then continue reading from that position (odds are in the middle of a word), and repeat the process to read the next "screen width" for as many screens worth of text the line might flow into. Setting textwidth will move the overflow text to the next line, but only after Inserting a newline character. Inserting newlines is not an option for code which will not compile when lines are broken up with newlines, or for writing that needs to have defined paragraphs delimited by newline characters as with normal word processing. (If wrap or other methods give only a visual appearance of line wrapping, this of course does nothing for a blind user, whose screen reader still sees only the first eighty characters.) I have also experimented using the screen command (ubuntu 16) from a cygwin window, which interestingly does show the long lines reflowed in a way that is visible to screen readers when scrolling up after using screen's C-a [ command. Using a standard program like screen would be great in combination with vim if anyone knows a way around what vim is doing with the text or window, or please advise about whether something like columns=10000 can be placed in the configuration to easily solve the problem. I am not familiar with vim scripting language but could learn enough to get by, and I have recently discovered that vim can be used with python3, so that would be an option too, though I would also like a simple solution that I can teach to others. Thank you to anyone who can provide feedback.

Vim is outstanding. It holds a lot of potential for blind users.

I still have one out-of-the-box problem when using vim with screen readers (tested with both NVDA and System Access). But that surely must have a quick and easy workaround, such as placing a single line in the vimrc:

When moving to a line longer than what appears to be a hard-coded maximum width of around eighty characters, there is no reading past that preset width. 

In other words, vim seems somehow to hide whatever doesn't fit on the screen, and that is where the screen reader stops reading. This is similar to Microsoft Notepad, in which there are about a thousand characters before a line break is imposed, although with Notepad the line is truly wrapped without inserting any kind of newline sequence (so that the text can be copied and pasted in its original form), and arrowing down in the Notepad window allows reading to continue.

With vim, regardless of the combinations of wrap, linebreak, and so on, that I have experimented with, the screen reading simply stops at that maximum line length. The screen reader will actually echo the column position when arrowing through a line (not with the movement commands unfortunately), so that starting from the beginning of the line and arrowing right states position 80 is reached, then counting starts over at 1 for the longer lines.

There are two major problems here:

The most obvious is that a blind user will have to jump to that last column position, arrow up or down, then back to the long line, which will then continue reading from that position (odds are in the middle of a word), and repeat the process to read the next "screen width" for as many screens worth of text the line might flow into.

Setting textwidth will move the overflow text to the next line, but only after Inserting a newline character. Inserting newlines is not an option for code which will not compile when lines are broken up with newlines, or for writing that needs to have defined paragraphs delimited by newline characters as with normal word processing. (If wrap or other methods give only a visual appearance of line wrapping, this of course does nothing for a blind user, whose screen reader still sees only the first eighty characters.)

I have also experimented using the screen command (ubuntu 16) from a cygwin window, which interestingly does show the long lines reflowed in a way that is visible to screen readers when scrolling up after using screen's C-a [ command.

Using a standard program like screen would be great in combination with vim if anyone knows a way around what vim is doing with the text or window, or please advise about whether something like columns=10000 can be placed in the configuration to easily solve the problem. I am not familiar with vim scripting language but could learn enough to get by, and I have recently discovered that vim can be used with python3, so that would be an option too, though I would also like a simple solution that I can teach to others. 

Thank you to anyone who can provide feedback.