[BRLTTY] Footsteps towards better accessibility in Linux

Tue May 6 11:16:46 UTC 2025

Hi again,

Thanks for all the really interesting posts; I was aware of a lot of this from the outside, and it has been very interesting to have these insights.

I know the triggers in the FLOSS world are inconveniently more complex than the applications of tyrannical or commercial power,  but there are some overlaps. Some distros, at least, are interested in the adoption of Linux on the desktop as more than a hobbyist pursuit, especially with the Windows 10 situation. On the other side, as in all good anarchist setups, shame and community pressure are the key drivers (see: LeGuin), which may mean a multi-pronged approach is needed, viz:

i. pressure on distros and the larger projects to make accessibility guidelines by applied more rigorously (and the word guideline is unfortunate here)

ii) rolling a set of core accessibility-proofed apps and DE configurations that distros might offer as an option, and which might encourage serious players to get their apps into the core. I am thinking of someone moving to Linux for the first time, or dealing with a developing or new condition, and switching to an accessibility-oriented setup. Part of this might be better onboarding and documentation accessible in an obvious way from the initial login, e.g. a doc folder in the home directory. It is a lot quicker and easier to use nmcli or bluetoothctl, as a sight-impaired person, than grappling with  menus and applets that are inaccessible, but the invocations are not immediately obvious - and the barrier can be reduced. [OK, I know that nmcli d wifi connect <blah> is less painful, but it takes some finding out.

iii) Keep filing the bug reports, of course for any who aren't moved by i) and ii). But this is never going to be enough by itself.

This is disability politics 101, but making it easier for disabled folk will make things easier for most other users; and that doesn't mean making it harder to configure things, quite the reverse.

The stability vs innovation (or breaking things) is very ... current ... in politics generally, but I am not sure we can resolve that here :-)

Isabel

On Tue, May 06, 2025 at 11:58:40AM +0200, Mario Lang wrote:
> 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,
>   ⡍⠁⠗⠊⠕
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at brltty.app
> For general information, go to: http://brltty.app/mailman/listinfo/brltty

-- 
Isabel A. Ruffell
Mobile/Signal: +44 (0)7813 101934
email: isabel.ruffell at talktalk.net
Mastodon: @iaruffell at mastodon.scot
Web: http://artemisia.scot