Re: Feature Proposal: Accessibility on by default

[Benjamin Otte <otte gnome org>]

Colin Walters <walters <at> verbum.org> writes:

> I'm not talking about the implementation details of the toggling
> of the switch, but rather the fallout on the rest of the stack.
> 
So, here's a simple technical overview of how the a11y stack works for a GTK app
(Clutter is similar). Imagine this as layers.

1) GTK 3
   compile-time links against (*)
2) ATK
   may run-time load a plugin that is named
3) atk-bridge
   compile-time links against
4) libatspi
   talks over dbus with
5) libatspi
   compile-time links against
6) Orca

You can easily see that there is a very brittle link between step 2 and 3.
Toggling the switch to always-on would just mean we always load the plugin.
The big advantage in that approach is twofold:
A) a11y users don't have to hunt for the "on" toggle anymore which is one
crucial step less in bringing up an accessible desktop. With that, we can also
remove a lot of switch-toggling and -querying everywhere in our a11y plumbing.
B) We know that the next step of linking everything at compile-time will not
cause any fallout once we decide to do it.

> I suppose your proposed plan of "try it and see what happens" is
> about the best we can currently do given the state of our current
> technology, but I was wondering if you had any idea of what the
> results might be.
> 
As the plugin does not do anything when no AT is loaded, there should be no
observable difference. Of course, that's the theory. And while theory and
practice are the same in theory, we know they might not be in practice. So the
goal is to find the bugs that the people running with a11y on (but no AT
running) have not yet discovered and fix them in the next 6 months.

Benjamin


(*) GTK 2 does this linkage at run-time, too, using the "gail" plugin. But GTK 3
has integrated gail recently, so this step is already always-on.