[BRLTTY] Footsteps towards better accessibility in Linux

Mario Lang mlang at blind.guru
Tue May 6 09:58:40 UTC 2025


Aura Kelloniemi <kaura.dev at sange.fi> writes:

> Hi,
>
> On 2025-05-06 at 07:09 +0200, Mario Lang <mlang at blind.guru> wrote:
>  > "Jason J.G. White" <jason at jasonjgw.net> writes:
>
>  > > On 1/4/25 05:46, Aura Kelloniemi wrote:
>  > >> 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?
>  > > The GNOME Foundation obtained grant funding to work on a new
>  > > accessibility architecture, which was developed as a prototype. If
>  > > funding sources could be found, continuing that work would probably
>  > > lead to valuable, long-term improvements.
>
>  > Oh no, not again.  That would be the third time GNOME starts over.
>  > Given what I saw while watching the D-Bus AT-SPI rewrite, followed
>  > by the early GNOME3 fallout, I have to admit I am
>  > not confident that GNOME actually can provide long-term stable
>  > accessibility support.  Sure, with proper funding, everything
>  > can be done.  However, as GNOME3 showed, shiny-new-stuff can easily
>  > kill existing Accessibility support just because.
>  > We'd need to obtain a substantially huge piece of funding
>  > to "motivate" developers to keep existing Accessibility features alive.
>
> And if developers need ongoing motivation it will become quite expensive.

Yes.  Funding was magically not really a problem in
the early days when AT-SPI and the first screen readers were
developed.  The Sun Accessibility Office basically did
most of the ground-work, with very taltented employees.
Sun reportedly was motivated to get GNOME to a certain level
of Accessibility compliance since they were planning to
use it as the native desktop on their products.

How it does work inside of the various desktop environments currently I
don't know.  From experience, devs are generally positive
if spoken to directly about Accessibility.  However, that doesn't really
mean they will have time to get things fixed if you come up with some
concrete bug to work on.  It took a HackerNews rant and the resulting
publicity to get Qt people to fix TextArea with JAWS after months of
waiting for action after having filed a ticket.
The truth is, only truly mean people would go as far
as telling you "no" when you chat about Accessibility.
But you might hear a different answer if you could listen in on internal
discussions.  At the end of the day, the day only as 24 hours.

As Jobs has demonstrated, you can order top-down
that Accessibility is a thing now.  All you need to do is allocate a
budget.  As it turned out, Apple didn't go bankrupt because they started
to ship VoiceOver, despite the small user count.
Google basically followed with Android because Apple set a precedence.
Basically "Apple has this, why do you not?".

However, I am not into FLOSS politics, so I have no vision
of how a similar sentiment could be established in the Linux Desktop
landscape and/or amongst distributions.

> Do you see any hope in resolving the accessibility issues? My experience is
> that quite many developers are willing to take accessibility into account as
> long as it is reasonably simply (or somebody sends them a patch) and it does
> not affect the applications resource usage. Thus I believe that if the right
> APIs were available at the right level, getting developers to support
> accessibility would not be that big deal (at least when it comes to
> applications, libraries and toolkits might be a different thing).

The ATK is the API you're talking about on the application side.  That
exists since the beginning, and could always be used to
improve the accessibility tree published to screen readers.

However, as you hint, libraries and toolkits is what threw Linux
GUI Accessibility back.  AT-SPI used to use CORBA as a basis, since
GNOME used CORBA for IPC.  Qt never wanted to adopt CORBA, but wanted to
support AT-SPI.  When GNOME finally decided to redo
AT-SPI based on D-Bus, the rewrite didn't go very smoothly.
It took time, and used to have a lot of silly bugs in its early days.
But once that was sorted through, GNOME3 introduced enough
toolkit changes that things like widgets on the desktop no longer worked.

This is pretty much why Mate used to be popular amongst
Linux Accessibility users since GNOME2 final  releases was
at a point where it could actually be used quite comfortably.
Since that moment in time, we're basically fighting an uphill battle to
keep things working.  If its not modernizing the toolkit, someone will
come up with a new windowing system, and everytime we need to adapt.

> Or do you think that Linux end-user software is always changing so rapidly
> that always if something is accessible, it is already on brink of deprecation?

Right now, everything outside of the console feels that
way to me.  Its a rather sad story, given that we're talking roughly
20 years of GUI Accessibility on Linux.

> Personally I don't want to be tied to any particular desktop environment, and
> I believe that applies to most of us here. I don't care about GUIs either (per
> se), but I don't want to write a separate program (that works in console) to
> solve problems that already have solutions, because it is a lot of work. I am
> also very bored with things that are broken in console.

I am well aware of the limitations of the console.
I don't really know how to solve the funding/motivation problem
in the wider open source context.  All we really can do is
follow the spirit of FLOSS and contribute to what is there now.

-- 
CYa,
  ⡍⠁⠗⠊⠕


More information about the BRLTTY mailing list