[BRLTTY] Footsteps towards better accessibility in Linux

[Elias Oltmanns]

Hi all,

On 2025-04-03 at 21:42:18 (+0200), Nicolas Pitre <nico at fluxnic.net> wrote:
> 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!

Well, if memory serves me right, Samuel had to raise the alarm rather
forcefully in order to keep character injection working only a few years
ago. My impression was that he may have had a hard time getting his
patches into the main line kernel exactly because there are not many
people comfortable touching the old code and because most users were not
affected. It was impressive and quite a stroke of luck to the
unsuspecting braille user that Samuel not only saw this issue coming
very early on but also was able to provide patches and persuade people
to merge them eventually. The watch dog part of this will be required
whatever component the accessibility stack relies upon, but there are
good reasons to believe that getting patches merged into ancient parts
of the linux kernel is and should be harder than more recent code
running in user space.

>
>> 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

Very commendable, indeed. Thank you very much for that! In fact, I do
remember that I was very positively surprised one day to find out that
unicode support had much improved since I had last tried and given up
several years before.

> 
> 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?

This may very well be the problem for the cases I am aware of. Writing
this email in Emacs within tmux running on the console right now, the
space after 😊 gets swallowed on my braille display.Subsequent editing
on the same line gets very confusing because characters change position
or double on a screen refresh.

>
>> 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.

Even though I have had some experience with loadkeys and modifying
keyboard tables, I often had a hard time finding the documentation and
examples that helped me along the way. So, thank you for providing this
example, but if most people would be working in the console environment,
distros would have included this in their standard configuration or
people would not be using key combinations like this in the first place.

> 
> 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.

Agaain, this is to the more general point that sharing as big a part of
the critical code base with the general public lessens the burden of
keeping and spreading the knowledge how to use and maintain the rest
within the smaller group of braille users (or console users for that
matter).

[...]
>> 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.

As I said, the console still is my favourite environment. But keeping
something alive comes at a cost. The console user base in general seems
to be shrinking steadily and it is a fair question whether braille users
can and should rely on this environment as heavily as they (or I at
least) used to. Apart from that, I personally find myself more and more
often find a situation where I have to weight the convenience of the
console environment in terms of braille user support against some
feature or application that is supported either only or at least
considerably better in a different environment.

So, the nice thing is that we actually have a choice between sustaining
the console experience and improving the GUI experience, the hard thing
is to figure out where to invest our resources most effectively. That is
why I welcome Auras initiative for this discussion.

Best regards,

Elias