From mboxrd@z Thu Jan 1 00:00:00 1970 From: blinux-list at redhat.com (Linux for blind general discussion) Date: Sun, 25 Sep 2022 13:10:01 -0700 Subject: slack in Ubintu? In-Reply-To: (Sebastian LaVine's message of "Sun, 25 Sep 2022 13:54:31 -0400") References: <87fsgf7472.fsf@aol.com> Message-ID: List-Id: > Do you happen to know of any resources on screen-reader friendliness for > TUIs in general? Is there any particular way screen-readers know how to > distinguish from actual text and "graphical" elements? Or a way that TUI > program developers can accomodate that? Here comes a wall of pontification... Not really. As a rule, I avoid TUIs. Interfaces that exploit the cursor-addressable terminal seem like the worst of both the text and GUI world to me. Essentially, a TUI is just a GUI with a VT100 as the canvas and typically no underlying object toolkit[1]. But don't let that discourage you. I use three types of interfaces. 1. Self-voicing. I make heavy use of Emacs with the Emacspeak extension. Emacs can be a TUI or a GUI program, and with extensions like Emacspeak and speechd.el, it can be a self-voicing program as well. Editing text is a great UI metaphor. 2. Teletype-style programs, either with their own interactive input loops, or called directly from the shell. Edbrowse is an example of the former category. The reddit client I use, reddio, is an example of the latter. There's an excellent opinion piece about teletype-style interaction written by Karl Dahlke: . 3. GUIs, when I must. [1] As a thought experiment, we could imagine an object toolkit for the terminal: a GTK or QT for the VT100, if you will. It's been done before, though I don't remember any citations off the top of my head. In theory, such a toolkit could provide hooks for screenreaders, to give a more seamless / less frustrating experience. That hasn't been done, and I don't know if it would be worth doing. -- Chris