[BRLTTY] Linux console hacking (was: Re: Footsteps towards better accessibility in Linux)

[Aura Kelloniemi]

Hi list,

On 2026-03-28 at 20:23 -0400, Nicolas Pitre <nico at fluxnic.net> wrote:
 > On Sat, 28 Mar 2026, Halim Sahin wrote:

 > > That was right but the development started again.
 > > Please read this:
 > > https://www.phoronix.com/news/Fedora-44-Approved-KMSCON

 > Well... I'm not holding my breath. If some day this works well _and_ it 
 > has proper hooks for BRLTTY to provide the same level of functionalities 
 > as the Linux VT console then the switch will be easy and we'll all 
 > rejoyce. In the mean time I won't stand still and wait for that to 
 > happen. So I'm still doing what I can to keep the Linux VT above the 
 > "usable" state.

I’m not holding my breath either, but there is a long history in the Linux
world of adopting half-finished technology. For example, many distributions
switched to Unicode consoles before they worked properly in non‑English
locales.

This suggests that accessibility is not a primary concern for distribution
maintainers when they adopt new technology. Linux VTs may remain in most
official distro kernels for quite some time, but more specialized
distributions, such as postmarketOS, may decide to drop VT support when a
user‑space replacement is available.

kmscon is under active development, and if Fedora adopts it successfully, I
expect Arch and other distributions to follow. I don’t see any sign that
kmscon developers are focusing on accessibility on their own: a quick search
in their git logs and issues for “accessibility”, “a11y”, “braille”, and
“speech” turns up nothing.

If we want BRLTTY support in kmscon, we will likely have to initiate that
ourselves: contact the developers and work out how best to integrate it. I
think this is important, because the Linux console is unlikely to gain the
features many sighted users now expect: high‑quality TrueType fonts, full RGB
color, richer mouse support, working scrollback, clipboard, etc. These are
precisely the kinds of features that motivate projects like kmscon.

This also seems like a good opportunity to explore a more general solution
that would allow BRLTTY to interact with other modern terminal emulators,
those running under Wayland. We might consider also contacting developers of
kitty or alacritty at the same time to find a solution that would fit all. A
unified interface (perhaps via a shared library) would probably be more
attractive to terminal emulator developers than multiple ad‑hoc approaches,
and would reduce maintenance burdens for everyone.

I’m not saying that improving the Linux console is a bad idea; it’s valuable
as long as people use it and the recent improvements have made my life easier.
But as long as it lacks the features that attract sighted users, it risks
becoming a niche tool. If we remain tied only to the VT console while the
broader ecosystem moves on, we may eventually find that we are the only ones
still relying on it, and that makes our tools fragile. It seems wise to stay
engaged with where terminal development is actually heading.

-- 
Aura