[BRLTTY] Footsteps towards better accessibility in Linux

[Nicolas Pitre]

My comments are inline below.

On Tue, 1 Apr 2025, Aura Kelloniemi wrote:

> Most of us, I believe, are using the Linux console daily. It works quite
> nicely for most of us, I think. There are some issues though: most
> importantly, sighted people generally don't use Linux console nowadays.
> Linux's console infrastructure is pretty much deprecated and the code receives
> very little maintenance.

I didn't see any deprecation notice yet. And the code receives little 
maintenance because for the most part it just works!

> There are cricital bugs in the Linux console affecting us. One of them is that
> many Unicode double-width and zero-width characters are not recognized as such
> which leads to serious rendering issues with all applications when these
> characters (like emojis) are printed to the console.

When I became annoyed enough with not being able to benefit from Unicode 
support while using BRLTTY on the Linux console, I just rolled up my 
sleeves and implemented the needed functionality:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d21b0be246bf3bbf

Now if you have specific examples of double-width Unicode values that 
don't display properly then please share them and I'll be happy to have 
a look. That's what I'm willing to contribute.

There is also the issue of BRLTTY itself trying to remove the space 
filler used to double the width of such characters messing up alignment 
with other elements on the screen, in which case this would be BRLTTY 
itself the culprit. Are you sure this isn't your case?

> The other problem important to many of us is that Linux console does not
> support extended keyboard input, like shifted cursor keys. This is very
> limiting especially in newer termianl applications. Using Org-mode for example
> without shifted/CTRLed/METAed cursor keys is unpleasant. As people who mostly
> do not use mouse, good keyboard input support is a top priority.

Just try this. Create a file called, say, custom.map and add those two 
lines to it:

string F50 = "Hello there!"
keycode 103 = Up F50

Then execute this (as root): loadkeys custom.map

Then enjoy the result when you type shift+up_arrow.

In fact, I just used the following key bindings to experiment with 
bracketed paste:

string F50 = "\033[200~"
string F51 = "\033[201~"
keycode 103 = Up F50
keycode 108 = Down F51

With this, even without any bracketed paste support in BRLTTY, I just 
need to do this while in vim, or at the bash prompt, or in weechat:

1. type shift+up_arrow
2. perform a paste with BRLTTY
3. type shift+down_arrow
4. marvel at the result

So there you have it: a makeshift bracketed paste that takes only 30 
seconds to implement. Works directly in the Linux console.

> There are hacks which add extended keyboard support to Linux console in some
> degree. However, there are limitations which these hacks cannot overcome, such
> as the number of definable function keys and the fact that applications
> relying on terminfo or termcap do not recognize the added escape sequences. In
> addition these hacks have received little testing, do not work universally and
> are not part of any distribution.

Augmenting terminfo/termcap is not that difficult. And many applications 
simply dispense with them for common sequences anyway (as exemplified by 
my bracketed paste experiment above). So this is a non-issue.

If you do test those hacks and turn them into proper proposals, and 
advocate for those to be part of a distribution to the right maintainer, 
then eventually they'll be part of a distribution. It is that easy.

> Linux console experience for sighted users is even worse than for us. The
> Linux console font can have at most 512 different glyphs (which is not enough
> nowadays). Also the colour support is limited and buggy. Linux console does
> not support text attributes, such as underline, bold, standout, etc.

True, although the 512 limit comes from the old VGA support. Nowadays the 
Linux VT console is mostly using a graphical framebuffer. So this limit 
is pretty much arbitrary.

At some point there were talks about simply moving console support to 
user space entirely. There is in fact many possibilities out there but 
according to https://bylr.info/articles/2022/10/29/til-textual-fb-term/ 
this isn't gaining much traction.

BRLTTY itself has a built-in console emulator which can be easily 
extended to keep track of whatever text attributes you want for direct 
consumption for braille output. Certainly much much easier than trying 
to interface with whatever other terminal emulators out there. It simply 
needs someone to volunteer for the work.

[ skipping over the GUI stuff ]

> I'd like to ask now, what do you people think? Do you agree with me that the
> above mentioned things are issues and that we would benefit from things
> getting fixed?

Absolutely!

> More important question of course is, is there something we can do about it.

Absolutely. It's just a matter of getting involved.

> We would need to decide, whether we want to improve the Linux console side of
> things or should we invest resources in improving desktop accessibility.

Why not both?

I'd say the Linux console is probably easier by far simply because it 
isn't such a moving target compared to GUI environments. It is not 
_dying_ either, especially if we keep it alive by making it even more 
useful. Even simple fixes count in showing interest in keeping it alive. 
And the return on the available investment is likely to be higher as 
well.

> I don't know the desktop accessibility infrastructure very well, neither do I
> know the people in there. But what I know is that there is lots of code and we
> might not have the resources to get big improvements rocking without help.
> Thus I started to think, would there be some organizations/companies which
> would be interested in sponsoring such development.

Sponsorship usually comes with expectation of some benefits in return 
(like visibility, publicity). Otherwise this is called charity.
Personally, I know of none.

> Does somebody know, if the funding options have been thoroughly evaluated and
> how easy/difficult it would be to get even one developer a long-term payment
> for working with accessibility?

Such evaluation, too, comes with someone dedicating time to do it.

That could come in the form of some government grant or subsidies. But 
those require that you submit paperwork justifying your case, etc. 
Again, involvement is needed. It's not always about writing code.

Alternatively, someone could start a GoFundMe campaign, or seek funding 
from organizations like CNIB in Canada, NFB in the US, RNIB in the UK, 
etc. But those are typically busy advocating for more accessibility on 
Windows and Apple products for which, by the way, you still have to pay 
hard money to acquire them (which creates some incentive for those 
companies to do something about accessibility) whereas Linux and its 
accessibility tools are available for free and relying on people 
volunteering their time for the most part.

What are you eager to volunteer for?


Nicolas