From: blinux-list at redhat.com (Linux for blind general discussion)
Subject: slack in Ubintu?
Date: Sun, 25 Sep 2022 13:10:01 -0700 [thread overview]
Message-ID: <mailman.2648.1664137007.6079.blinux-list@redhat.com> (raw)
In-Reply-To: <CN5OB5WYJNS2.34IEXFK1NRMYF@archlinux-x220> (Sebastian LaVine's message of "Sun, 25 Sep 2022 13:54:31 -0400")
> 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: <https://www.eklhad.net/philosophy.html>.
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
next prev parent reply other threads:[~ UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.64.2209251225030.2246441@server2.shellworld.net>
[not found] ` <87fsgf7472.fsf@aol.com>
` blinux-list
[not found] ` <CN5OB5WYJNS2.34IEXFK1NRMYF@archlinux-x220>
` blinux-list
` blinux-list [this message]
` blinux-list
blinux-list
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mailman.2648.1664137007.6079.blinux-list@redhat.com \
--to=blinux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).