public inbox for blinux-list@redhat.com
 help / color / mirror / Atom feed
From: blinux-list at redhat.com (Linux for blind general discussion)
Subject: slack in Ubintu?
Date: Sun, 25 Sep 2022 22:44:22 +0000	[thread overview]
Message-ID: <mailman.2361.1664138674.6074.blinux-list@redhat.com> (raw)
In-Reply-To: <mailman.2648.1664137007.6079.blinux-list@redhat.com>

What Chris said... And sorry if that does not address the question, but let's
not forget the Linux console aka tty.

No graphical element, only actual text, so no such issue.

Didier

Le 25/09/2022 ? 20:10, Linux for blind general discussion a ?crit?:
>> 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


  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
       ` blinux-list [this message]
 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.2361.1664138674.6074.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).