BTW, do you know if TUI programs (using curses/ncurses or related) are usable for blind users?
Pure clis (where you type commands and get answers) are okay. Ncurses apps are sorta kinda usable, but a native GUI is way better. With a real web browser or native GUI, a screen reader has access to semantic information, so it can tell you that you've reached a table with 3 rows and 5 columns. It can then let you navigate that table by row, by column, by a mix of both, or in whatever way you choose. With a terminal UI, all you have is dashes and vertical bars, which will be [read as dashes and vertical bars. You can make sense of them, given enough time and patience, but GUIs are just way easier.
The guideline I give for accessibility of textual interfaces is "make it look good in a non-monospaced font, with no color support". Don't expect character 33 in line 12 to be directly under character 33 in line 11. If nothing breaks, you're probably good to go.
Original comment:
Supporting terminal-based and line-mode browsers doesn't prevent you from supporting graphical browsers with screenreader support; on the contrary, it can actually help improve cross-browser compatibility by encouraging authors to use simpler progressively-enhanced technologies.
Using a textual browser encourages authors to focus on text, and to think twice about non-textual content. Tables and images have their place, but should be used judiciously when ordinary text simply won't convey an idea well. The result is an even more accessible page for everyone, whether they're using a braille reader, dictation, "reader mode", a printout, or a hacky webpage-to-markdown-to-epub shell script.
Supporting 100 edge cases with under four users each is too much to ask, but supporting plain-text browsers automatically covers a wide variety of such edge cases with no additional effort.