[BRLTTY] Footsteps towards better accessibility in Linux

[Sébastien Hinderer]

Aura Kelloniemi (2025/05/07 00:15 +0300):
>  > What would be the benefit, compared to the additional latency?
> 
> There are several. Most of them are related to usage scenarios where Linux
> virtual consoles are not the only environment where the user is working.
> 
> - Resource usage: if the user does not use VTs (or they are not available),
>   having a core BRLTTY that reads unused screens, parses configuration files,
>   manages braille tables, starts a speech driver, etc. is useless. All
>   BRLTTY's screen reading features would be just extra bloat (and would also
>   be additional attack surface).

It's possible to make BRLTTY rather minimal, e.g. by compiling it with
the no screen driver. FWIW a project like the one you describe did exist
years ago, it was called libbraille and as far as I know nobody used it.

> - Multiple displays: if the user uses multiple displays (like I sometimes do),
>   they cannot connect them all to the same BRLTTY instance. Running a second
>   BRLTTY for the second display does not help, if the user wants to use
>   anything that relies on BrlAPI.

Well in text mode having two instances of BRLTTY works, a bunch of times
I hacked with blind friends and we did manage to do that. It's true that
it's not yet well supported at the BrlAPI client leel, but it's not
inconceivable that clients connect to several instances of BrlAPI at the
same time.

The only think that I might be hard to achieve is the synchronization of
the different braille displays, but (1) it's probably not completely
impossible to implement on top of BrlAPI parameters, and (2) I guess
it's not unconceivable either to imagine that BRLTTY runs several
braille drivers at the same time. So for that I don't see how decoupling
BrlAPI from brltty would help.

I'd like to add that on this front I do not think NVDA competes. I can't
think of a way to use two braille displays simultaneously with NVDA, not
even in a terminal.

> - Better support for BrlAPI-enabled applications: currently it is non-trivial
>   to write BrlAPI applications which don't utilize BRLTTY's command set in
>   their input handling. BRLTTY's command set works well if the application is
>   a terminal screen reader, but this becomes a limitation if the application
>   does something different.

I think the set of commands could be enriched as much as desired. I can
even imagine a notion of context which would allow to bind a key to
differnet commands. Also, the only thing you have to do if you do not
want BRLTTY commands is to ask for key codes whenyou enter in tty mode.
And finally, I am skeptical about thae fact that splitting BRLTTY from
BrlAPI would lead to progress in this direction. Well even if it would,
that progress would have to outweight the manpower necessary to do that
split and which is scarce and may be better used on a different front.

>   For example I have written an e-book reader for BrlAPI, but BRLTTY does not
>   have commands for navigating menus, exiting contexts, activating buttons,
>   etc. Thus the application works well only with my display and with my custom
>   BRLTTY key bindings.

I'm sure this can be discussed and improved without changing the current
architecture.

Did you publish the tool? Would be happy to give it a try, although I am
a super happy user of the nov.el Emacs mode for reading ePubs.

>   Separating BrlAPI from terminal screen reading (BRLTTY)
>   would require rethinking the interface between the application and BrlAPI
>   server.

Likely, and as I said, given the work that would represent and the
scarceness of resources, I woudl rather think twice if not more before
doing that. I thihnk I would have to be convinced that somehtign that is
very important is simply not achievable in the current set-up. I am not
saying I cannot be ocnvinced, but I am saying I am not, at this stage.

> - Resource usage again: if the user runs several BRLTTYs (e.g. one for
>   console, one for gnome-terminal, one for some other terminal emulator, etc.)
>   the BRLTTY binaries will all contain code for the BrlAPI server and this
>   code will be kept in memory, even though only the core instance of BRLTTY
>   runs the server.

It's possible to compile BRLTTY without the server so if
desired/necessary, that could be done.

Also, in the same way it may be possible to embed several braille
drivers in an instance of BRLTTY, it may also be possible to run several
screen drivers in the same instance.

Seb.