[BRLTTY] Footsteps towards better accessibility in Linux

Nicolas Pitre nico at fluxnic.net
Wed May 21 16:33:55 UTC 2025


On Sat, 5 Apr 2025, Elias Oltmanns wrote:

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

Yep. I provided a little persuasion nudge too.

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

For the record, in the last month or so, I've contributed a total of 24 
patches modifying the Linux console that are on their way for inclusion 
in Linux v6.16. They cover:

- Updated character double-width handling (moved from Unicode 5.0 to 16.0)

- Added support for zero-width characters

- added support for Unicode decomposition

- Display of a fallback glyph when the actual glyph is unavailable

- Native support for bracketed paste (with a hook for BRLTTY's benefit)

- Extension to obtain the cursor position on screens larger than 256x256 characters

So it is not as hard as it may seem if you are serious.

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

This will be fixed once you start using that new kernel.

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

I strongly prefer working in a console environments, which is why I've 
focused my development efforts and contributions there. Working 
independently, I've made useful progress. We have to recognize that 
creating equivalent GUI functionality would require a team effort rather 
than a solo endeavor though.

In any case, involvement is required. Nothing ever happens without it.


Nicolas


More information about the BRLTTY mailing list